@karllynn 这是什么理由，日志里有密码信息你们不会上脱密吗？而且你以为 post 就不打日志了，打 RequestBody 的日志系统又不是没有。

@yikyo 现在是前端喜欢找事，只要后端没有搞出安全问题，该给的文档给清晰，你管后端一个接口提供 Get 还是 Post，如果说一个接口只提供 Get，或者只提供 Post，那你倒是要问问后端的理由是什么，大部分时候都提供有什么不可以？

@mringg 不存在，post 和 get 根本不存在所谓的安全问题，你觉得你不把数据放在 get url 上，放在 post 的 requestBody 里就安全了啊？哦，对，如果上 https 的话，requestBody 会加密，那样可以算安全点。就正常来讲，说 post 安全 get 不安全，我就笑笑

@warcraft1236 少扯淡规范，真要按规范，前端那普遍连类型校验都没有的开发方式是严重的不符合规范。别动不动读了点标准就在那自以为是，流程和规范在真实的实施场景里都是有成本的，视你自己项目和组织的规模大小而定。又不是金科玉律

@HuasLeung 前端变化快？不好意思，MVVM 是微软 2005 年搞出来的，现在三大前端框架不就是绕着这玩意变来变去吗

@wc951 中间件的特点是距离业务有一定距离，不和业务直接关联，真要用到必须原生 sql 直接上的，都是和业务强相关，此时中间件就失灵了，中间件不能屏蔽 sql 的复杂度

jpa 最大的问题，不光是楼主说的“ SQL 是复杂的”。要我来说的话，JPA 上下不靠：

1.该简单的时候简单不起来，你们去看看别的动态语言，尤其是 ActiveRecord 和链式调用的创始者 Ruby on Rail，是怎么处理单表查询的，是怎么用链式调用拼查询条件的。JPA 压根就做不到这么简单

1.该复杂的时候恶心的要死，需要写原生 SQL 的场合 JPA 那个费劲，那个丑陋啊。。。

根本原因在于，关系模型和对象模型是有区别的，老是有人生搬硬套想用对象模型去描述关系模型，也不想想这招要能成功的话，关系数据库不早就被对象数据库干掉了？

Java 界的 Spring Data JPA 和.net 界 Entity Framework，都是上个时代面向对象思想到高峰时的典型产物，其实压根就不符合现在这个时代，Sql 现在越来越有生命力，想彻底屏蔽 sql 细节，别做梦了

@mmdsun 迁移数据库是伪命题，这已经不是数据库群雄争霸的时代了，你能遇上一次项目更换数据库，那简直可以去买彩票

一般来说应该是你开了缓存导致的

我在一堆.net 库里试验了一圈，最终确定 sqlsugar 很好用，EF 太重了

你领导没错，存储过程的维护成本和程序的维护成本完全不是一个级别的。除非不得不用存储过程，否则别用存储过程

英语到这个级别了，我觉得做翻译比做前端赚钱。
英语对于计算机的作用，在于能更快的看到前沿科技发展的论文。你要是去搞计算机科学，那有很大优势，搞普通的开发，没什么优势

起点低？搞笑呢，500w 的学区房都到手的人说自己起点低？
你知足吧，有时间想干啥都可以，如果你再国企是正式工的话这辈子基本不会有失业的风险，有想法是好的，问题是你出去就要面对 35 岁扫地出门这个风险，考虑好了再行动。
最后说一句，干码农年轻的时候总会觉得自己技术好无所不能，等上了年纪才会意识到技术不是最重要的。有资源，有时间，能轻松的把有技术甩出 3 条街去。技术只能让你饿不死而已，别指望靠技术发财。楼主现在已经有时间了，估计技术就算不强也是中等水平，好好蹲在国企花时间积累资源吧。别听上面说的什么跑出去创业。
创业公司生存潜规则：好好搞业务，别想不开做研发

是傻子太多，骗子不够用，所以自然敢许下这种诺言

职场是战场，做好你的本职工作就行了，别管其他的事情。还有，职场无朋友

新手应认真研究 Dom

@yangbotool 等一下，你这个方式如何做模糊查询，我没想明白