@nonoyang
应该说 skuID 对应的产品 ID 永远不会变
但是 spu 表和 sku 表的 isActive 会经常改变，
这个时候除非把 spuIsActive 和 skuIsActive 还有 pid 增加到 tbl_price 这里；
但是引申出问题就是 spu 和 sku 的可售状态改变(isActive)，那 tbl_price 将进行大量更新.

@nonoyang skuID 对应的产品 ID 是唯一的；


@lenmore
@2i2Re2PLMaDnghL
@zoharSoul
因为实际情况还有以下几个环节，一开始漏了写上来：

```
tbl_product:
id：唯一主键
isAcitve：int(1)上架 /下架
...

tbl_spu:
id：主键
pid:int 对应 tbl_product.id
isActive:int(1)上架 /下架
...

tbl_sku:
id:主键
spuID:int 对应 tbl_spu.id
isActive:int(1)上架 /下架
...

tbl_price:
skuID：对应 tbl_sku.id
bookDate：日期
isActive:int(1)可售 /停售
price:int 价格
/*其中 skuID+bookDate 为联合主键*/

SQL:

SELECT
p.*,min(price) as price
from
tbl_product p LEFT JOIN
tbl_spu spu ON spu.pid = p.id LEFT JOIN
tbl_sku sku ON sku.spuID = spu.id LEFT JOIN
tbl_price price ON price.skuID = sku.id
WHERE
p.isActive = 1
AND spu.isActive = 1
AND sku.isActive = 1
AND price.isActive = 1
AND price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
AND price.price > 0
GROUP BY p.id
LIMIT 10


逻辑是查询 10 个可售产品；
可售定义是 product/sku/spu/price 的 isActive 均为 1 且 tbl_price 的 price 大于零 且 价格范围在 '2021-10-10 ~ 2021-10-17'
所以价格表无法冗余；

```



@chenzheyu
ORM 感觉只是方便了 SQL 语句的读写，对于性能而言不会有帮助吧；
left join 改为 where in 方式我还没试过，等等去试试，但估计结果差不多。

偷懒：
前端翻译，直接翻译成各国语言。

精准：
直接加字段 ，字段 x 语言数。

直观：
多库，搞好中文的，copy and paste 。

实际项目中，一般要求高的客户（翻译精准度），都是用方案 2 来解决，但他们都是中英形式。
大多数的客户，他们由于没有专业人员翻译，英简都是直接反代第三方翻译 API 缓存结果前端展示的形式。
简繁的话就直接系统转换，自己修正下。

钉钉没研究过，但微信就是跑 nodejs，开发者工具和企业微信一样。
我觉得没必要在乎它用什么写...
而你们前端提到的我觉得和是否 web 形式毫无关联...
在 web 中本来就没有限制字数的功能（ textarea ），
都是靠 JS 来实现的，
JS 绑定的触发不同，实现出来的逻辑表现就不同；
比方我绑定 onChange/input 时，输入的时候就会出现你提到的问题。
但是如果我绑定的是 blur，那就不会出现这个问题。

@iqoo
函数式 和 方法式 我觉得没必要要求统一...
当然仅仅是个人习惯而已，
针对前端 1 年以上经验的，哪种使用方法调用和哪种使用函数调用基本都了解了。
但是突如其来都变成函数式，他还要去追代码看......

我知道不能以我的个人习惯去否决其他人的个人习惯，
只能说对我而言意义不大，毕竟我只是个后端，前端太多东西让人眼花缭乱....

虽然说每件大事都是由一堆看不起眼的小事组合而成的，
但是我觉得没这个必要...
就如 1# 2# 所说到的，
如果这种做法成为常态，那应该是编译器上干的事，把所有原生方法都克隆一份出来，再给出个文档介绍如何使用，而不是应用级别需要去考虑的。
---我不是专业前端，只是出于流程上进行考虑。

@Ritter 可以...
轻量升级唯一条件就是 1C2G 60GB 大陆的，然后参加活动（找 5 个人帮你点助力）
你可以加轻量产品群，产品经理都在里面，剩余多久时间都是免费升级，不过这次活动对比之前真的不是那么吸引

uniapp.ink
amy.pet
321.vin
mee.ink
lol.pet
wechat.kim
jmp.bio
qcloud.sale
didiyun.ltd
didiyun.life
zhidaojintianwocaifaxianyuanlaiyumingzhendekyinamenamedechanga.com

@0kaka 具体问题具体分析吧，
这问题就像双向车发生交通事故，算谁的责任？
没有具体原因也不好确定。

我个人认为，类似这种涉及第三方的，首先要看清楚技术文档，是否有提及过这些场景和规避方法，如果技术文档有提及到（类似你举例的），那肯定就是技术逻辑问题了。
如果不涉及第三方的，那严格来说就是产品逻辑问题。

比如：
某终端设备，产品需求本来就是要联网的，但是客户断网这些情况就属于不可抗力因素，客户找来基本都是把问题推给客户自身网络导致。
后期产品经理就会考虑到各种因素，然后增加联网 /脱机 版........

而且针对你这个问题，
小程序扫码支付提交订单
提交的时候突然断网了(客户端断网还是服务端断网)
> 可能出现银行卡已经扣费但后台没有收到订单的情况
如果是客户端断网，那微信支付的异步通知是通知服务端，客户端就算把卡拔了也没关系才对啊。
如果是服务端断网，那么这个影响就不是单纯支付这一块了

微信支付文档中有提及过的；
1 、当遇到非正常情况 /支付后没直接返回 成功 /不成功 的消息时，应当调用查单接口对交易进行查询；
2 、小程序提交支付无论是否成功，都不应当以接口返回消息为准，应当以异步回调通知为主；


统一下单->开启支付结果轮询
|---拉起支付
(轮询结果)
|--成功 ---支付成功
|--拉起支付 有返回或异常，但轮询结果为未支付-->后台查单

其实讨论这个问题我觉得有点离题了。
问题本身精简而言就是 防篡改参数。

基于 WEB 形式,基本无解，哪怕你对请求参数进行加密，然后再把 JS 代码各种加密，最终别人甚至不需要解密你的 JS，直接 devtools 上打点，看看哪里是对参数加密的，把加密函数复制出来就可以了。（我之前遇到过大多数的都是这样
高深一点的，通过浏览器特性进行加密，类似携程防爬原理，某些特性某版本的浏览器是支持 /不支持的，通过这些差异来进行加密，后端通过请求的 ua 和规则验证下，就知道是否被篡改 /爬虫的请求了。

基于 APP 形式的：
这种玩法就多了，
一、使用自定协议
二、sdk 中写加密函数，分发 sdk 给第三方而不是给请求地址第三方
........

但其实就如楼上有人提过，不是不能破解，而是当破解效益低于破解成本时，没人会去破解；
现在很多第三方直接开通开放平台，接口我也直接给你调用，这种情况下谁还会去分析破解呢？
包括 v2ex，直接开放了 API 。

@xiaooloong 我觉得有没意义是一回事，是否能拦截也是一回事；
而且我说的是针对前端参数可信情况，而你说的是个人电脑安全情况，完全不是一回事吧，
再者，我可以在虚拟机中装 Fiddler 进行拦截吧？（当然我没这样做过，我都是开发机直接装 Fiddler 来的）


@zyxk 没办法防，参考微信 web 版本，他们最后手段也只是根据注册账号的时间和使用频率等方面，限制账号是否能通过 web 登录。
而客户端的话可以采用 sdk 进行加密，甚至可以自定义协议。

其实微信就是一个最好参考对象；

第一、https 和这个没关系吧。装个 Fiddler，你就算是 https 还不一样能拦截篡改。
第二、address 生成是由客户端生成，那就不存在不能篡改，你要防止篡改的话只能由服务端生成。因为客户端生成的话你无法区分 address 是被篡改后的还是没被篡改，当然你可以对参数请求进行签名，但这样无疑只是增加破解的成本而已，别人只要反编译下或者多次对比，找出你加密的规则，那最后还不是一样照篡改你的数据。
最后：前端提交的一切内容都应该视为不可信内容。

@pydiff #147
@Donahue #151
的确，光威真的.....海康的是之前 jd 活动买的，本来期望不太高，但不曾想过一直掉盘，好烦。
intel 只能说高端好，低端其实也就那样。。。。
之前 sata ssd 买过 ocz，一直坚挺到现在，速度有下跌，但从未异常 /掉盘；
也买过东芝的 sata ssd，3 块坏了 2 块。

@pydiff intel 、光威、海康 的 nvme 我都用过，其中 intel 的 2 个月出现丢盘，保修后半年没事，但偶尔也会出现丢盘，不过重启后就正常了。光威的是公司用的，买了 12 个，有 8 个出现丢盘，2~3 个主控挂了。海康的自用，经常掉盘，但主控没挂，现在挂载去硬盘盒用，但是单次写入量大的时候发烫严重，然后掉盘，现在基本成了摆设....
听说三星比较好，但没试过，如果你在用的不错麻烦推荐下给个牌子型号。

如果房东有几十间房子，估计他都丢给中介管理了。

我朋友城中村地方，起了 3 栋楼，都是单间，1 层 4 间，共 6 层。
他是直接外包给别人，他负责起楼核装修，别人负责买家电和出租。
每月固定支付租金给我朋友，约定 10 年后家电归我朋友。

如果你要线上收，支付点数是个问题，估计没多少个愿意承担。
如果不是线上收款，那和开个 excel 记账有什么区别呢。。。

我自己的理解，

无状态 token 一般都是根据具体权限进行加密生成出来，接收到的时候解密验证权限，不存在加载用户信息。
比如登陆后的读写操作。
生成 token：md5 （ uid +md5 （ 1+1 ））
前端提交：token，uid （明文）
后台验证：
可读：md5(uid+md5(1)) || md5(uid+md5(2))
读写：md5(uid+md5(2))
*日志要记录就用 uid 就行了。

实际上生成规则还需要加入随机数等的，都是生成时候后端传给前端，后续前端都需要携带这些服务端才能验证，作用时防止被猜到验证规则。

然后还有一种 jwt，
这种直接把参数放入载荷里，传给前端，由于解密需要 key，所以前端是没法解密的，但是后端只需要获取到 jwt 就能解密出来。
一般情况下，你把用户 id，昵称，性别，头像，权限这些丢进去载体，
后端解密后就能直接用了，不存在查数据库。
jwt 加密方式是根据这些参数进行加密的，所以如果前端改了这些参数，加密的结果就会不一样，除非把 key 给碰撞出来了。
*很多文档都说不要把私密信息放载体，但我觉得如果对方能解密出来，那载体放什么已经不重要了。

最后，由于是无状态，那么踢出用户 或限制 不能多端登录类的无法实现，这时候可以配合 redis 做个黑名单功能，后端验证 jwt 前都查一次是否存在 redis 黑名单里，存在里面的就直接返回失败。

@WebKit #7 好吧，我审题错误，sdk 加固也有，但都要收费。