我对世界没看法

这事情的本质是：后端只管安全不管用户体验，前端完全负责用户体验，是否有可行性
至少在注入这件事上，我想说没有可行性，用 SQL 参数带来的体验前端不能完全 cover 住
当然在另外一些事上是可能有可行性的，要就事论事

@Leon6868 tctc4869 说的并不全无道理，后端不搞过滤只搞拦截，安全性并没有什么损失

你咋不用营销号生成器再生成个正文呢？ Angular 好好的，依然是重型企业级研发的首选
到了现在这个时代，如果没有理念上的完全突破，3 个主流框架是不会怎么样的

我觉得他说的 2 不合理，但 1 是对的，不如重构单独一个 commit，用 message 详细说明改了什么为什么改，后人也能 blame 看到

当然可以不用，只不过当熟悉这些框架以后，大概率效率和可维护性是能有效提升的

@Perry 如果写的是 JS （用带 d.ts 的库），现在有什么工具能方便地加这个类型检测吗，我这边也遇到类似的问题想找个工具给 JS 做检测

先和实习生本人说，明确把问题说了就完整了，实习生又不是给公司钱的，明确问题不改进就辞退，最多给 3 次机会呗

@Perry 因为 IDE 的辅助支持是没办法确保类型正确的，天下不合格的程序员千千万万，没有一个 warning 连后人发现问题帮着修的机会都会消失
我更倾向于有工具在编译的时候通过 ts 自动生成 propTypes

前面说上 TS 的那些……你写个组件发出去能确保使用者都是 TS 吗

这个病要小心，他提到的表现可以和很多人对上，但有这个表现不一定就是植物神经紊乱。所以有一些相关的表现最好还是就医确诊，不要私自以为是植物神经的问题就买药吃了，小则没用大则耽误病情

你想要做出一个好产品自己有满足感，那肯定是会提的。你就想上班下班发工资，那肯定是不会提的

dump 差不多就是把一盒果冻 piaji 一下倒到盘子上的这个过程，我觉得这里强调的是一个整体性，完整的一个导出去，而不是分块分片的（你不能把果冻搅碎了）

中间加一层 BFF，爱怎么改就怎么改，不修改后面的实际业务服务

state 是个数据的容器，本身不是数据。state 里面的每一个属性才是数据
容器没必要不可变，但容器里面的数据必须不可变

几乎每季新番好听的歌网易都没版权，不想换也只能换了

@auroraccc Suspense 处理异步，Error Boundary 处理异常： https://github.com/ecomfe/react-suspense-boundary