订单成功的语义很含混，如果是中间状态，会用 wait_to_pay, paid, delivering, received,如果是结束状态，会用 closed 。

我之前一个项目也是如此，明明可以用 MQ ，非要用接口调用，最终说不清到底是谁的锅

赶快分手吧，不要勉强别人和自己。


@sciel btw ，爱情和婚姻是两回事儿，爱情是为了自己，婚姻是为了生育

@mogutouer 以前安全技术办不到这种监控或者可能是成本问题，我以前碰到过一家公司，是直接安装摄像头对准员工电脑屏幕。。。

现在的企业安全软件，基本上只要安装了就没有任何隐私，包括苹果手机。

如果 lz 不想回答，干嘛还要去面试呢？如果双方什么都知道，面试或者沟通都毫无意义。。。

特别是，面试者如果以为对方会把你的简历逐字逐句看一遍，那就太天真了，大多数面试者都是等你到公司了，才把简历打印出来翻一下。

你再能买能好过卡宴宝马 7 吗？真的只有穷人才考虑牌面，结果正好适得其反，对经济差距保持正念更重要。

作为过来人，压力承受不了，说出来会好很多，另外，睡不着可以试试分房睡，可以大幅改善睡眠质量。

这分数在小学的确算差的了，我小孩上六年级，期末成绩现在只给 ABCD ，其中 A 是三门课平均 90 分以上的，他所在的班级有 33 人是 A ，其他等级只有 9 个。我小孩是贪玩不爱学习的，三门课平均分刚好 90 分多一点，也就是已经是倒数 10 名左右了。学校只是三四线城市的公立学校，已经在贯彻减负了，所以平时作业大幅减少，但是这个成绩从五年级转进去开始都是差不多的水平。

我在 mba m1 上用 pd 装 win11 ，尽管是 8g 内存，但是软件打开还是很丝滑的，包括资源管理器。。。

@JasonLaw 不一定非要用分布式事务来解决。一是可以用工作流来处理，二是可以用 MQ 半事务，分布式事务个人觉得不可靠，是最后的选择。

接口设计，当业务体量小的时候，怎么搞都没问题。既然是看一本书的相关订单，那就是后台应用，没有并发压力，设计方案基本上靠 PK 解决。

token 设计并没有问题，只是不应该前端判断“快”到期了就去刷新一下，而是 accesstoken 失效后，前端处理这个返回异常时，再用 refreshtoken 刷新一下，可以获得 accesstoken 。虽然我也觉得这么搞很麻烦，可是设计上把 accesstoken 的过期时间设置的短一些，是为了提高安全性。

lz 的需求是个共识系统，或者是工作流？

不要买，买了肯定吃灰——除非你有私密照片需要打印

lz 说的都是自己不知道的事儿，而不是以为自己知道，但其实不知道——这种情况，我以为通常出现在，自己以为是 common sense ，但是有一天忽然被启蒙，发现并不是平常想象的那样。

苹果电脑上的鼠标，我只用过 trackpad1 和 2 ，基本上没有飘过，如果飘了通常是没电或者机器快卡死了。另外，用黑苹果时，如果网卡天线旁边有 USB ，蓝牙鼠标非常容易飘或者卡，据说是互相干扰了，我用铝箔纸隔开天线就好了。

这么大表，不是分库分表，就是同步到 nosql 库，没有其他方案了，也许 newsql 可以，不过我不太了解。

查询慢，是因为主键采用了 varchar 而不是 int ，使用有序整型做主键是大表的基本设计原则。

10 年前我就购买过一次这样的选衣服务，一次性寄过来一两套衣服，不喜欢的免费寄回，当时觉得很激动——穷人家啥时候享受过专人定制？后来想想，实在是太傻了，再也不想购买这种服务了。

曾经在上班之余同时接四个外包项目，当时以为自己很牛逼了，后来发现是我飘了，疫情以来，外包项目几乎归零，还是老老实实上班