@Alicewish 这不是具体的难不难、要求高不高的问题，这是思维角度的问题。你是站在工具制作者的角度，而不是站在用户角度。

如果你的期望是要求用户自己付出一点的努力（你认为非常小）来使用你的工具，那么就把这个观点准确明确地写在你的工具文档里。

你既然坚持站在工具制作者的角度去思考这件事情，那么就必然要承认会有用户不符合你用户画像的现实。这是每个做产品的人都知道的行业常识，你也许没有这个经验，我是从过来人的角度去告诉你这个事实。

我没有在和你争论学习东西的要求算不算高，我说了不算，你说了也不算，这件事情最终买单的是用户，谁有本事能说服所有用户？这本身就是不现实的事情。你要接受的就是你的工具不可能满足所有人，能够满足你期望的那部分用户就已经是成功了。对于那些不愿意付出努力去使用你的工具的用户，无视就行了。

浅尝截止，摸清自己的需求和预算。

看你在这件事情中的的整体思路变化

1.需要一个电脑桌（基本需求）
2.在一个自己觉得可信的渠道（多位 B 站知名 UP ）了解到黑胡桃木可靠美观（事实）、价格昂贵（事实）
3.陷入“黑胡桃木”黑洞（在某个领域内深挖比较，和烧 HIFI 、烧键盘是一个道理）
4.需求重心转移：需要一个好看的、用料好的黑胡桃木（在自己花了大量时间深挖后，觉得应该有一个成果，这个成果的最终体现就是购买行为），顺便当一个电脑桌。（安慰自己花了钱还是有用处的。）
5.后悔（突然想起了自己最原始的需求），根本不需要一个“好的黑胡桃木”电脑桌

@Alicewish 你的努力值得认可，但是把愿意自我驱动学习的要求加在用户身上就是思维方式有问题了。

考虑以下问题：
你做的产品想给什么样用户使用？
是有经验的开发者？
是有自我学习编程能力的漫画爱好者？
是爱好漫画的伸手党？
在这些用户群里，哪些占比大？哪些最能体现你产品的价值？

典型的幸存者偏差：“知乎和抖音搜索“顺丰 拉黑”，找到了很多被拉黑的事。”，你都定向搜索这个主题了，那么全网全部时间的投诉聚合到一起，你看到量的就是很多，可是你是看不到占比的。那些没被拉黑的案例和正常用户的案例，你要怎么搜索统计出来呢？

“顺丰是不是很容易拉黑用户？”，这种问法有很明显的引导倾向，无论你是有意还是无意的，结果就是下面的评论绝对不会是你所希望的心平气和的讨论了。

如果你的标题是《快递是否有拉黑用户机制》，那么这个主题就是中性的，大家是可以理性展开讨论的。

分开看消息的处理流程
1.从消息队列中取消息
2.用消息去执行业务逻辑

当 1 和 2 同步时，就容易产生消息队列的消息堆积，影响线上增量实时消息。
当 1 和 2 异步时，取消息速度非常快，不会产生消息堆积，把取到的消息放到另外的存储介质里，异步取数据慢慢执行业务逻辑。

消息顺序性是有局限性的，基于什么范围内要保证顺序的？全局？单个用户？单个门店？单个商户？顺序性的范围越小，维护成本越低，并发处理性能越高。

没需求不要创造需求，没有什么应不应该的，只有自己需要的，每个人是不同的，少看看别人，多看看自己。

看楼主描述： [就是假国企，没有国企的命却得了国企的病] ，应该是在着装要求出来之前就已经对公司反感了，着装要求只是最后一根稻草。

如果是一家福利待遇都很不错的公司，就算出了着装要求，也不会这么反感。

看了看评论区，变成了关于“公司要求穿西装，这点要求算不算高”的讨论，但真正的问题是“已经对现在的公司很不满意了，最近又出了着装要求，放大的对公司的反感”。

你现在两个分支合并的难点在于日积月累产生的大量冲突，这不是具体合并方式能解决的。

git 工作流是在项目推进过程中起作用的，帮助每次迭代快速解决小量冲突，而不是在项目不遵循工作流导致分支管理出问题了，开始想用 git 工作流解决已经产生的问题。这不是 git 工作流的用法，git 工作流的存在是在事前避免这种情况，而不是事后解决这种情况。

无论用哪种方式，最终的瓶颈都是解决冲突，只能靠熟悉这两个分支的开发人员去手动解决冲突，没捷径。

你完全可以在一个 varchar(255) 字段上去创建一个前缀索引 INDEX(column_name(10))，这里的 10 就是前缀索引的长度，这个值表示对 varchar(255) 字段里的前 10 个字符做索引。

varchar(100) 中的 100 指的是字符数，这个字段最多可以存 100 个字符，不论这个字符是具体哪个语言的。

utf8mb4 是变长字符集，一个字符最多可以用 4 个字节表示。

索引长度指的是字节数，在 REDUNDANT or COMPACT row format 下，最多支持 767 个字节。
在 utf8mb4 字符集下按每个字符最多占用 4 个字节来计算，那就是最多支持 191 个字符。



具体看官方文档：
https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html

The index key prefix length limit is 3072 bytes for InnoDB tables that use DYNAMIC or COMPRESSED row format.

The index key prefix length limit is 767 bytes for InnoDB tables that use the REDUNDANT or COMPACT row format. For example, you might hit this limit with a column prefix index of more than 191 characters on a TEXT or VARCHAR column, assuming a utf8mb4 character set and the maximum of 4 bytes for each character.

Attempting to use an index key prefix length that exceeds the limit returns an error.

If you reduce the InnoDB page size to 8KB or 4KB by specifying the innodb_page_size option when creating the MySQL instance, the maximum length of the index key is lowered proportionally, based on the limit of 3072 bytes for a 16KB page size. That is, the maximum index key length is 1536 bytes when the page size is 8KB, and 768 bytes when the page size is 4KB.

The limits that apply to index key prefixes also apply to full-column index keys.

为了避免配置繁杂问题，用起来更方便，所以有了 mybatis-plus 。

保存 openid 和手机号关系，老用户登陆不需要重新授权手机号的。
用静默登陆 wx.login 拿 token ，传给后端去换 openid ，就能定位到是哪个用户了。

切换手机号同理，保存一份当前用户和已授权手机号的一对多关系，找不到老手机号时才让用户去授权新手机号。

lz 的提问方式是典型的 xy 问题。

对于 X-Y Problem 的意思如下：

1 ）有人想解决问题 X
2 ）他觉得 Y 可能是解决 X 问题的方法
3 ）但是他不知道 Y 应该怎么做
4 ）于是他去问别人 Y 应该怎么做？

简而言之，没有去问怎么解决问题 X ，而是去问解决方案 Y 应该怎么去实现和操作。于是乎：

1 ）热心的人们帮助并告诉这个人 Y 应该怎么搞，但是大家都觉得 Y 这个方案有点怪异。
2 ）在经过大量地讨论和浪费了大量的时间后，热心的人终于明白了原始的问题 X 是怎么一回事。
3 ）于是大家都发现，Y 根本就不是用来解决 X 的合适的方案。

X-Y Problem 最大的严重的问题就是：在一个根本错误的方向上浪费他人大量的时间和精力！

一个系统具有多个较复杂的幂等查询功能，内部用户使用。
但发现内部用户太多使用自动化手段、模拟正常用户登录，反复调用幂等查询，造成查询所占资源紧张。
尤其是内部正常用户之间还会借用多账号等手段，增加自动化并发能力。
希望通过一些手段控制，这些用户自动化重复调用、消耗系统资源的情况。

看了你的需求，这不是 nonce 能解决的场景。
对用调用量过多的情况，可以使用接口调用限流来控制，降低自动化调用的效率。
对于复杂查询，可以从查询缓存，异步计算角度去考虑。

nonce 是用来保证明文的不可预测性。

当明文非常容易预测时：
举例：
请求 1 明文 money=10 ，签名 abc 。
请求 2 明文 money=10 ，签名 abc 。
请求 3 明文 money=10 ，签名 abc 。
这 3 个请求的明文是相同的，非常好预测，没有随机性，那么攻击者收集足够多的请求样本后，就知道明文和密文的直接对应关系了，就可以得到一个明文和密文的字典了，类比彩虹表。

当在明文中加上了 nonce ，保证不可预测性
举例：
请求 1 明文 money=10&nonce=q1w2e3r4 签名 1234
请求 2 明文 money=10&nonce=5t4r3e2w1 签名 4567
请求 3 明文 money=10&nonce=5t6y7u8i9 签名 6787
虽然这 3 个请求中都是 10 元，但是明文不同，导致签名也不同，攻击者无法通过收集的样本，分析出明文 10 元和签名的关系。

我是从不可预测性来解释 nonce 的作用，和具体的技术实现没有关系，和前端还是后端实现没有关系。

评论区马上就出现有线吸尘器和无绳吸尘器支持者的互喷。

找到适合自己的产品不就好了，为什么一定要去用自己的使用场景去证明别人是错的呢？

躺着用的话，就选 ipad mini 这个系列，重量适合长时间手拿。

ikbc c87 红轴