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

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

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

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

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

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 红轴

还有种办法是 google [hustle etymology] ，查单词的词源，可以得到更加准确的解释。

google [hustle meaning] ，先理解这个单词在不同词性下的具体含义和用法，这样才能准确知道对应的含义是什么（注意这里和语言无关），而不是对应的中文词语是什么。

理解一个英文单词，本质是去理解它的含义，只有理解了含义，才知道应该选择哪个中文词语去表达。

中英字典的一个最大问题就是没有将含义表达清楚，直接给了一个中文词语，这就导致了不准确。

先打个预防针，仲裁成功不是终点。就算仲裁成功，公司还可以继续拖着不执行，需要你去法院申请强制执行。最终赔偿方式可能不是一次性全部赔偿，而是每月分期赔偿。

品牌里要看具体产品线的，比如时尚休闲类的，还是运动表现类。

拿阿迪达斯来讲
时尚休闲类的，比如三叶草产品线，那确实没什么技术壁垒好谈的，缓震回弹耐磨都很一般，脚感坚如磐石那是正常的。
运动表现类的，比如 Ultraboost 跑鞋系列，那鞋子的整体穿着感会舒服很多，甚至感觉不到鞋子的存在，很贴合。

鞋子确实是消耗品，但只要你找到一双很舒服的鞋子，那很大概率是你不会想穿自己鞋柜里那些不太舒服的鞋子了。

品牌有影响力，会吸引人去尝试，但要找到一双适合自己的鞋子，应该要去了解具体的产品线的定位，否则就会出现满怀期望买了双名牌，结果发现穿得不舒服，这是因为不懂产品导致选错产品了。

看你的使用频率这么低的话，感觉没必要上七千多的价位了，这个价位已经是高端定位了，适合对电视品质要求比较高、使用频率也高的用户。

我建议在明确 75 寸的条件下，在中端和低端产品里找一下。
优先考虑亮度和颜色，这两点是适用度最广的，优先考虑平时看新闻和电视剧的场景，电影和游戏不用防盗考虑范围内。
分区背光和游戏在没有需求的情况下，不用去考虑的。