满足她一个愿望

你们没有独立的开发/测试环境的吗？一般都在内网架设服务器，搞一套完整的开发环境，再搞一套或几套完整的测试环境。这些环境运维只负责搭建不负责管理，管理都是开发自己的事。但生产环境，你们休想要任何权限。

class java.util.LinkedHashMap cannot be cast to class

连表查询慢首先要看执行计划，执行计划没问题，那就是数据量的问题。数据量问题也不一定是单表量大的问题，有可能只是笛卡尔积比较大的问题。

客户端的技术其实源远流长，但是，前端在 web 上为了和桌面客户端划清界限，完全抛弃了历史和传承，导致走了太多太长的弯路。

因为 Java 没有 namespace ，但是有 package 。事实上这两者基本上是一回事。但是，Java 也没有一个类一个 package 的说法呀？

@ospider 时序图也可以用流程图代替，UML 就是没有任何卵用。

就算业务系统出问题，因为权限批不下来耽搁好多天，关你 P 事？何况非业务系统

私有化部署后和你们就没关系了呀，怎么还要去管理？

只要符合自己的预期就行。一份正常的工作而已，哪来的那么多坑。反而一些不正规的小企业会更坑吧。

堂下何人状告本官呐。。。

错误代码并不关键。因为绝大部分的情况下，你仅能告诉用户出错了。而且，大多数的错误，你甚至无法告知用户出错的原因。

只有极少数的情况，你能够并期望用户可以明确地做出响应。只有这种情况需要安排特定的错误代码，其余情况，更加有用的是错误消息而不是错误代码。也就是说，一个错误代码，不同或者相同的错误消息（你无法告知具体错误原因的时候）几乎就能应对 99.99%的异常了。然后，针对具体的几个期望客户端能够作出正确的应对策略的异常，约定独特的错误代码即可。

JWT 做不到有状态。所以，正确的做法是放弃 JWT ，自己实现一个有状态的 token ，非常简单。

数据权限可以抽象，但必须要约定数据筛选字段，缺点是无法支持分页。要支持分页，就必须在查询 sql 中注入额外的查询条件，这个实现起来相当复杂，我一般都是直接拼条件了。
@NutChocHoney

可以看看人家丁蟹是怎么操作的

抓包，模拟接口调用。要什么 root……要什么机械臂……怕什么活体检测

想不明白 id 加密有什么用？只要够大且离散，一个个试的成本就足够高。就算给你试出来一个真实存在的 id ，你又能做什么呢？