快进到 帖子进 “水深火热”节点的时候。

很有同感。 代码死掉了，会难受。 其实更难受的是，当你明明知道接下来要建的房子一定会是一个失败品连它的设计师也对它不上心的时候，但却还是要投入时间去把它建出来。 那种心情，写个 if-else ，我能写一个下午，大部分时间都在 emo 。

@debuggerx 同意。不看场景，拿着锤子找钉子，用起来当然痛苦。我现在看到论坛拼命鼓吹一项新技术，都会有点反感，因为以前也被这样“骗”过。。。

你都 headless 了，为啥还绑定 react…… + 1

估计这种恶心的改动都是来自 “哎呀，这么牛逼的功能怎么没什么人用啊。”。 然后一堆强制拉流量的骚操作就出现了。

没调教出格式化工具，就老老实实用第一种。

1. 低代码不好限制系统边界。你提供了拖拽配置能力，给了一般用户想象空间，提高用户的期望值。
2. 要用好，避免不了二次开发。所以简单用用可以，要想用好，就得学习对应的低代码系统二次开发。别指望什么问题都可以通过用户或者技术客服 拖拖拽拽就能搞定。
3. 低代码肯定能提高开发新模块的效率。但是别封装过头了，会砸自己的脚。
4. 低代码系统达到简单的配置是不够的，除非只是自己用，或者只服务少量客户。面向 toB 的低代码系统，最好要构建足够好的错误收集、debug 工具、样例数据构建、部署工具、(技术)客服工具、二次开发文档 sdk 、升级测试等等基础设施。链路很长。。。

别对 gpt 有严肃期待，这种姿势不太正确。。。

主要现在实在不想学什么新框架、新架构。感觉业务开发的方向实在是很浮躁——业务也好、实现业务所用的技术也好。 所以想试着了解一些计算机领域的其它应用，刚好又能驱动自己去重新学习底层技术，同时也有所应用。

想想反正是在玩一游戏，总有一些重复操作的枯燥事情。

之前主要是使用 ocr 来实现 游戏状态判断，但是不太稳定，而且感觉效率低。

@seers oh~~~ 这玩意粗看 似乎不错。

@roycestevie6761 哈哈。谢谢分享！

@danbai 好，谢谢~ 我去往这个方向试试。

钱，凡是离开自己的手，就要当作没了。 那种说，“过几天还的”，就是在公然要你给钱，别指望能还你。

怎么感觉讨论跑偏了。

就我个人而言，一些情况下我会主动加班，比如觉得新功能很有意思，或者实现的方式能让我学到一些东西，或者不可抗拒力导致的紧急需求或问题等等。其它时候加班，我都是不情愿的，尤其是那种很 sb 的需求，或者需求改来改去导致的工期延误。个人应对方式是向上管理，明确告诉 PM 要加时间，上线延期，我们公司还是比较 nice ，挺少加班的。

假设，我处在的公司要让员工加班，没事做也要加班，不然就会觉得你很闲。我大概会做如下措施：
1. 早点找下家；
2. ”磨洋工”，做功能我求质量，慢慢来。写完、自测、提测、修 Bug 的时候我做一些代码清理甚至是重构。高质量的完成。（但还是早点找下家）
3. 摸鱼，这种就真的“磨洋工”
4. 穿插点一些别的事情，如实现各小工具、学点什么东西。
5. PM 如果看到你的反馈后，很快又改需求，那你做好了东西就先晾着，帮他冷静一下。那种做了几版，最后选择第一版的人，职业能力真的不怎么样。不要有负罪感，你这是在帮公司省资源。个人最讨厌需求没想好，胡乱挥霍资源的产品经理。

当然，还有一些情况是无解的。就是上面常态化催着你加班，提前完成功能开发。这种我只能接受在开拓新业务，需要抢占市场的时候的加班。不然常态化打鸡血，真不是人能做到的。

有没有链接发一个？

预期的情况有两种：
1. 当你需要改动的时候，一定会产生 diff
2. 如果没有改动，则不能产生 diff

我的方案：直接用 JSON.parse/stringify 。你说的那种情况应该只有在原本的 JSON 字符串不是用 JSON.stringify 的情况下会产生。你可以先统一把已存在的文件全部重新格式化一遍，后续就不会产生 diff 。