@wtsm 不要怂，就是干。不然会逐渐萎靡

@maxmax4max 随便一个 中文 NLP 库都能实现

@yinmin 这个用例，从工作流上来说，还真是产品/前端/测试的直接责任，除非客户是跑接口触发的。用例不全的问题。 代码每一步都做异常检测，最后的代码是更难看的，难以迭代的，除非产品明确要求，一般就离业务最近的一层验证。非法参数就不管了，快速迭代。 看高分开源项目，完全不会像公司业务一样，到处都在做异常检测。

写文章批判他

@harlen #32 关于数据完整性检验的问题，我做技术总管，板子一定是打在后端的。 主要是从二点考虑： 1. 从安全性角度考虑：前端做校验，后端不做校验，黑客笑哈哈，黑客可以直接访问接口攻击系统的； 2. 从人性的角度考虑：如果后端不主动做校验，需要前端主动去 push 后端改代码加校验，但是后端能摆脸给前端啊，甚至能暗戳戳 pua 前端，几次下来，前端就会很纠结，从人性角度往往就有可能不去 push 后端校验了，前端做校验，测试能过，就得过且过了，安全隐患就此埋下。 做主管定责任，从业务流程角度考虑的同时，更多要考虑人性。

后端不做检验，我直接用 postman 给他塞错误日志，哈哈哈

@wusheng0 之前试过，结果还是要我承担，现在打算他说啥就是啥吧，不鸟他

不要正面硬刚，要向上级证明他能力不行，默默收集证据

@yinmin 1.事实上不存在，总有你想不到的用例存在，导致接口的完整性验证失败。特别是 多端同一个接口，每个端的需要的完整参数都不一样。 很多公司比较理想的化，开发阶段 测试列出所有用例，线上出现问题，如果是未定义的用例，开发/产品/测试 全扣绩效。 2.如果要穷尽所有的验证点，就单整理验证点，和实现验证点都要 很多工时，这种问题，上报工时的时候，组长都会觉得你脑子有问题。 也不利于产品的快速迭代。 要完全面对黑客开发，正常迭代都不用做了。

接口这种东西一般都是后端主动出吧，甚至没有产品的话后端也得做产品分析。所以有一个和自己配合默契的前/后端真的就珍惜吧