debuggerx

@ljzxloaf http 状态码 500 ，返回数据类似{"code": 610016, "msg": "余额不足"}
简单来说就是成功时 http 状态 200 ，响应数据直接是业务负载数据，错误时 http 状态非 200 ，然后响应数据返回业务错误码和信息文本

@ljzxloaf 并非只适用 http ，而是一种设计思路，websocket 、mqtt 也都可以用类似的设计。而且这并不是什么把业务状态放在协议里，http 协议的状态码本就希望服务器能够表达一些明确的意图，不管成功失败全用 200 才是自作聪明的反设计，曾经可能还有些场景有些理由这样做，现在可以扔掉这种惯性设计了。

@ljzxloaf 很简单，正常响应直接返回数据，http 状态吗 200 ；接口出错时，前端参数问题就用 400 状态码，服务器问题就用 500 ，然后响应结构：{"code": 业务定义的错误码, "msg": 错误描述或希望显示的文案}

前端 api 设计形式类似 static fetchItemById = (id: number, onError: (code: number, msg: string) => void): Promise<Item | null> => {...}

直接根据 http 状态码去解析，而不是先解析，再根据状态搞泛型

谁叫好好的响应数据非要包一层呢

我受不了的 java 味：
1. 无意义的抽象和继承，简单问题复杂化，自以为是预留扩展性，然而绝大多数情况下非但用不到，反而是增加了复杂度和项目维护成本（当然有人把这种操作当作防御式编程增加自身不可替代性，实际结果往往不过是叠屎山）
2. 滥用多线程。有些人似乎觉得 java 不写多线程很 low ，结果滥用多线程，没必要的时候也要强上，然而很多 javaer 实际的心智水平根本玩不转多线程，要么自以为提高效率的多线程实际比一般写法还慢，要么生产出现线程安全甚至死锁，纯纯又菜又爱玩自讨苦吃
3. 滥用架构。web 服务必上 redis ，设计必须拆成微服务，看似追求最近技术方案，然而却抱着 mysql5.7 、centos6 不放，整天还研究 java1.8 的 jvm 调参，就不想想守着这堆破烂搞架构的路子能走多远。
4. 把一些 java 本身缺陷导致的东西当作唯一正确性去要求别的语言和框架，比如语法贫瘠导致的各种设计模式，比如灵活性不足而不得不使用的反射技术，比如落后的线程模型催生的一堆教条，很多新的语言和框架从本身就已经解决或者规避了，有些 javaer 用的时候却还习惯性往上靠，靠的不对劲了还觉得是那些语言和框架不行，反正就是 java 祖宗之法不可变……

@murmur 这不叫味儿 这是 objc 本身语法和命名规范就这样

@zcf2009 不能说的明显指的是华子啊，军儿又和 BYD 们没啥冲突。。

我是用 flutter 按自己的喜好和需要写了个 APP 自用：
https://www.debuggerx.com/2024/12/08/weekly-todo-app/
https://github.com/debuggerx01/weekly_todo

@drymonfidelia 目测经典的长列表渲染问题，flutter 没用列表复用写法。只要写对了 60fps 不成问题，内存占用能少一半。