我不能理解 “用 spring ，又特意改为 fastjson” 这种操作。

我就是信了哪些吹 m1 air 可以拿来开发的，现在后悔了。
大部分时候 cpu 使用率在 20-25%, 偶尔会有几秒钟上升到 50-70%。
在这种使用强度下，室温 20 度，cpu 温度一直在 50 到 90 度之间徘徊，主要集中在 60-80 度。

事实上，我现在用的 IDEA 的界面， 比这个新 UI 简洁多了。

Intel Mac 是这样的，cpu 保持在 20%的情况下，风扇就能起飞，这能耗真的烂得离谱。
今天换了 M1 才发现，原来电脑可以这么流畅，我这两年就没用过流畅的电脑。
Intel 的移动端真垃圾。

手机用的是 WIFI 吗？ WIFI 节能也许会导致这种情况。
你 ping 手机 IP ，看下延迟是多少。我测试自己的手机，延迟高达 350ms

19 年用飞书的时候， 飞书文档就是在客户端打开的。
但是有严重 bug ，文档是多人编辑的，且用户无法关闭文档，导致切换到其他界面，文档依然在后台，非常吃性能。
当时使用 2017macbookpro ，只打开飞书，不做别的事情，不到两个小时就没电了。

@shadowfish0 第一次是上级带我走，第二次是前同事推荐，第三次是前前同事帮他朋友找。

你这一说，我想起来，我就刚毕业的时候面试过一次，还只有 10 分钟。
现在已经工作 10 年了，待了 4 家公司。

windows 轻薄本，AMD 4 代或者 5 代的低压 CPU 这种的，价格 3000 元就能买到。
惠普星系列 非常轻，方便携带。

DDD 难以落地的原因在于，它不是某项技术，而是思想。非常依赖于团队中关键成员的个人能力。
技术框架是看得见，摸得着的，只要不傻，就能入门。但思想不行。

个人理解：
DDD 是面向对象的实践总结。
我们在工作中，不必拘泥于 DDD ，不一定要遵守公认的 DDD 的开发模式，只需要使用其中的部分思想就会有很大帮助。
例如：帮助梳理业务流程，帮助团队间更好沟通等等。

入职手续，最重要的就是合同，合同也是可以远程办理的。

肯定不是为了防破解。我可以肯定，它是不想开发离线功能，因为离线不适合这个应用场景。
1. 在现在的网络条件下，用户设备基本随时都处于联网状态，除非用户自己断网。为了极小概率场景，专门开发离线功能不值得。
2. 即使有了离线功能，也无法保证数据不丢失，还会引起更大麻烦。这涉及到用户认知与事实的一致性问题。离线状态下，手机显示数据已经同步，然而事实上数据并未同步到服务器。一旦 APP 被卸载或者设备被重置或者丢失，都会导致数据丢失。这时候，用户只会认为是服务商把数据弄丢了。
3. 增加使用难度和用户负担。大部分人都没有基本的互联网知识，他不知道什么叫“离线”。为了一个极小概率场景，把“离线”这个概念输出给用户，只会增加使用难度。

@3dwelcome
后端删除通常是逻辑删除，那么还是会有更新时间的。
如果你的后端必须是物理删除，那么就需要传所有数据的 id ，进行对比了。
------------------------
另外，我认为这个需求是伪需求。
1. 使用压缩算法后，响应流量可以大大减少，1000 条数据，应该不会耗费多少流量。
2. 即使每条数据有 100 个字段，流量真的较大，那么应该分为两个接口，1 个接口拿列表，1 个接口拿详情。列表接口的响应流量还是会极少，详情接口的结果进行缓存。

个人看法
1. coding 让人专注于逻辑思维中，暂时忘记其他事情。
2. coding 是程序员最擅长的事情，做自己最擅长的事，让人对自己有种全面掌控的感觉，心里踏实。
3. 相对于娱乐，coding 让程序员觉得自己没有荒废时间，缓解焦虑。当然，并不是所有的程序员都这样，而且 coding 的内容不同，也会有不同的影响。

@cp19890714 抱歉，用平板打字，好多错字

你提供的信息有点少。我只能根据我看到的提出我的方案。
## 后段接口：
* 参数：updatTime-已有数据的最大更新时间。
* 逻辑：
1. 如果 updateTime 不是空，则查询数据时，根据 updateTime 筛选，并给出最大的 updateTime 。
2. 如果 updateTime 是空，则响应 1000 条数据，并给出最大的 updateTime 。
当有数据更新时，需要更新数据的 updateTime

## 前段
* 首次请求，没有 updateTime 参数，会得到 1000 条数据，以及 updateTime 。
* 下次请求，把 updateTime 传给后段，得到差异数据。并在此缓存 updateTime 。