找工作难，招人更难。

能走一定要走。
首先是金钱的损失。
不过更重要的是个人能力的增长。我一直觉得在大公司里修炼深度，创业公司修炼广度。

上次 1024，买一赠一。

ZFB 的接入流程就比较标准。可以参考下。主要是公私钥的生成，数据加验签。

前提是：不做物理删除，那么本质上所有的删除，其实就是更新。
如果是单体应用，事务管理是比较合适的。

佳明的手表了解一下。有用又不掉价。

岁数大了。
我上学和刚工作那会，一睡能睡到下午。现在也是晚睡早起，总感觉时间不够用。

1.5w 预算，可以考虑上 Sony 新出的 A8H 了。

所谓人为刀俎我为鱼肉，就是这样的。没有任何办法。

建议后端处理，这样更灵活。比如改个字什么的。

看情况，如果是专业的物流公司，必然选择第一种。如果是普通电商小公司，我会选择第二种。
首先第一种设计的很严谨，但是带来的数据行数过大。一个订单平均有 10 个左右的物流行数，不划算。而且设计的这么严谨其实没有用处。
第二种设计方式虽然看着简陋但很实用。能有效减少行数，适合小项目。至于有人说 update 复杂，其实数据处理完全可以放在应用中。
个人建议：
1 按状态分表。//因为物流信息一般是在订单未完成之前才关注，订单完成后几乎就是死数据，所以不妨在订单完成后，将此类数据迁移到另一个表。
2 增加缓存。//缓存按照 30 分钟进行刷新，避免用户着急刷新物流而导致的查询数据库过多。
3 换一个数据库 比如 mongo 或 ES 。

看会专业书。

Redis 足以实现一个简单高效的消息系统。
不推荐基于应用本身的，因为一旦重启，信息会丢失。实在不行数据库也可以。

@ConradG 一语道破真谛。1+1 是算法 for 循环也是。但是招聘上说的算法，显然不是这么简单的。大家习以为常，成了惯例。

且不考虑销售。
感觉按照这种思路做下去，会不可避免的变成项目外包。我在 YZ 就是这种感受，除了正常的产研需求，受大商家影响的情况也很大。问题是你们能不能从大商家繁杂不标准的需求中赚到钱呢？或者公司的人力足够多，能够快速的垒出一套全能的系统？

一般前端会要求传 B: {a: '', b: '', c: ''} ，而不是直接把 B 中的 abc 干掉。

刚买了小米的 AX3600.理论上好像是 3000 左右，路由器在客厅，mac 在卧室，基本上就剩下 700 了。