@lscho 对，我还真不知道 get 请求有可能会被缓存，我只知道 w3c 标准实现里，控制缓存由 http header cache-control 里，从没听说过根据 http method 类型来决定缓存的，默认 get 所以就缓存的标准和 http client 实现我还真没见过，你们不是比我见识多吗？让你们给出 get 请求就缓存的标准和 http client 实现。你们就是不给。让我说啥？

@rockyou12 因为我英文不够好所以我机翻，免得有人说我英文不好。你说不要机翻，行啊，你告诉我你这段哪里提到和缓存有关了

@rockyou12 你提到的 w3c 标准，我随便找了个机翻：

特别是，已经建立了这样的惯例：GET 和 HEAD 方法不应该具有采取除检索之外的动作的重要性。 这些方法应该被认为是“安全的”。 这允许用户代理以特殊方式表示其他方法，例如 POST，PUT 和 DELETE，以便使用户意识到正在请求可能不安全的操作。

请问哪里说了和缓存有关？

你不要转进好不好，你自己说的和缓存有关，你要说 http method 有提示用户安全性的作用，这个我承认（不过我们现实里不会用 http method 去表示安全，其实后端在接口实现上会考虑安全问题，而不是用 method 方式去提醒）。但是你自己在前面说的是缓存。

还有，http client 会对 get 进行缓存的例子，麻烦你举出来，现代一点的 http client。我还是那句话，就算是 http client。我倾向是你们没用对，而不是人家实现错了

@love 提 ts 之前我觉得你非常有必要弄明白一件事，node 本身是 js vm 环境，这个环境现在并不能像 jvm 那样，支持别的语言编译成字节码或者 jit 什么的直接跑，ts 一样要把自己编译成 js，才能跑在 node 上。ts 是很优秀，我经常也用，但是 ts 的存在，并不能解决 nodeJS 的窘境，除非哪天 Node 大升级，变成类似 JVM 那样的开发规范型虚拟机，其它语言直接 JIT

@rockyou12 到底谁该闭嘴啊，学了几个框架就出来教训人，你自己去翻 w3c 标准去，让不让缓存是由服务器决定的，服务器在返回的 http 头里没写让缓存的时候，浏览器凭什么缓存啊？如果现在还有这种不按 w3c 标准实现的浏览器请介绍给我开开眼，你看千万别把 IE6 这样的中古浏览器弄我面前，至于前端框架会按 Http Method 来决定是否缓存？我个人倾向是你根本不会用。我今天真是开眼了，今天居然有人在论坛里叫嚣说 http method 会决定前端是否缓存结果，并且要求别人闭嘴，麻烦去 w3c 标准里找出支持你结论的东西，再来让人闭嘴

@love 我这么说吧，虽然 go 的性能确实强很多，但是这里混的人，很少能遇到谈性能的场合的，python 那么慢的语言照样有大量的 web 服务在线上跑。

小公司偏向 Node 的原因和他们当年偏向 PHP 的原因是一样的——成型快，不考虑后期维护，反正小公司很少有项目能活过 3 年的，Node 比 PHP 的优势在于它的招人成本进一步变低了。大公司以前偏向 Java，因为他们有长期的业务需求，这类业务是绝对不能用动态语言构建的，无法维护和迭代。现在蹦出来一个语法是 C 系，资源占用比 Java 少的多，同时特性很少玩不出花样（这就意味着培训容易的多，且代码风格比较容易统一）。当然会倾向这个语言

@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 太重了