同 4 楼推荐的零刻迷你电脑主机

罗技鼠标上一般有收纳接收器的插槽的，就是来提前预防接收器找不到的问题。

七天无理由退货，放在任何平台上，都是和具体产品相关的，有些产品是拆分后可以退的，有些就不能退。

你这遇到的明显就是质量问题，直接走售后，bose 耳机质保一年的。

G304 用了 4 年，没有任何问题。

电源计划问题，你可以下载 Quick CPU 去解锁各种电源计划，还可以对比不同电源计划的明细差异，非常详细。

电源计划里分成直流（电池）和交流（插电源）的两种配置，平衡模式下，直流会选择更节能的配置，高性能模式下则侧重性能。

小电驴性能不如 F1 ，为什么还有这么多人用？

在能够满足需求的前提下，选择成本最小的，这就是权衡的核心思路。

@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 。