业务逻辑不放在前端是因为前端代码谁都能看见吗

@iugo #3 v 站前阵子有一堆 cursor 贴，你们都在骂，只有我开心的要命每天都有人免费送 gpt 不限量 api key (hardcode 在 index.js 里面)

@luoyou1014 #4 补充一点：为了最小的成本，高质量交付软件产品。

@pureGirl "啥叫前端数据不可信，那传到后端不也是不可信吗"

前端处理好的数据，在提交给服务器过程中是可以被客户端和中间人攻击篡改的。

你说你后端该不该信任前端提交过来的数据？

那如果后端不信任前端提交过来的处理结果，总是要检查校验，那还不如直接在后端处理。

因为前端上线要审核 临时修改很麻烦 又要什么 所以一般控制都写在后端

第一个场景：现在商品 A 的价格是 100 元，想上调到 300 。服务端：分布式动态配置，或者 apollo 之类的，锁库存，改价格，几秒生效。浏览器：本地静态资源缓存，cdn 缓存，新版本发布两天了还有用户再用老的 gitVersion 版本，业务跑不动。客户端：同样的道理，版本更新了没法保证立即全量。解决办法也有，前端业务做一个版本判断，但不太现实
第二个场景：一个接口，需要访问两次消息队列，三次 redis ，四次数据库，五次 rpc 调用，服务端内网是毫秒级延迟，保证分布式高可用。放在前端：寄
服务端可以做到对代码，流量，数据，运行环境的完全控制，前端写一些不重要的业务倒是没啥问题

@qingyingwan 场景三：某个业务要求全流程的日志记录，或者精确的 metric 上报。服务端：各种高可用的架构支持。放在前端：上一秒点击付款，下一秒关闭浏览器或者断网了，啥数据也没有
场景四：需要事务的时候，服务端能做到分布式事务。还没见过业务的事务放在前端。
深入服务端或者全栈就知道了，java 八股文没法成为前端八股文，就是前端解决不了那些问题

@qingyingwan 确实，主要是看场景，前后端实现业务逻辑的需求方向是不一样的，后端是必须做的，前端重新实现一遍则属于优化，可做可不做，且这种优化不能用于对流程数据实时性要求高的场景，这个就得靠团队自己把控了，前端控的好会让人感觉交互丝滑流畅，但是控的不好就会导致某些场景数据一致性问题被用户明显感知到，就属于反向优化了

这个算基本常识了，因为无论前端做不做，后端都要验证一遍，等于再做一遍，既然如此那前端就没必要做了

你怕是没经历过当年外挂满天飞的时代