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

不一定，有些交互的判断还是得前端做。

某些业务逻辑，例如判断某些数据是否存在，只能后端来

最近在写全栈，主要是后端先天不能过于相信传递来的数据，还是要自己进行校验，再重新处理，走一遍业务逻辑。前端做好展示就行。前端确实业务逻辑会少一点。toB 的或者企业内部管理系统，可能前端业务逻辑还多点。

如果是单体应用, 那么放在前端也没什么问题. 但目前大多数应用的数据是储存在后端的, 如果出现前端并发, 就需要在后端处理才能良好解决这类问题.

当然, 安全问题也是一个重要的考虑项. 比如第三方密钥 (比如 OpenAI API Key), 一定要储存在后端, 不能放在前端.

前端存在多端，安卓/ios/pc/H5/小程序……

业务逻辑放在前端的话，就要重复写很多遍，改的时候也要改很多遍，某一端漏改了，就会产生不一致的问题。

放在后端的话只要写一遍，其他原因都是次要的

前端 ui 界面多样化（比如 m 、pc... app ），一个接口往往可作用于多个 ui 模块。从耦合层面来看，丢后端往往只需处理一次

还有有些计算量大/重复计算/可以缓存在前端的东西, 可以利用一下 client, 给自己的服务器减少点压力.

我是游戏后端，如果业务放在前端，玩家作弊怎么办

前端负责渲染， 业务控制在 后端， 更可控，更灵活，且如果存在多端的情况下， 业务逻辑处理能够保持一致性；

前端不配

不知道你说的 业务逻辑 是指哪些？如果 业务逻辑有变动，是不是前端都需要跟新才行？

@HongXinss v8 引擎的计算性能还是可以的, 否则就没有 wasm 什么事情了.

前端 build 很慢呀，有点逻辑写错了上线是不是挺麻烦的

放后端只需要维护一个点，前段可能有多端

一般很多逻辑前后端都要做，后端做的目的是前端数据不可信，前端做的目的是摆脱接口请求带来的卡顿感，可以看很多操作丝滑的应用，都是把很多逻辑同时放到前端处理了，当然很多偏重技术的会觉得后端接口请求就一两百毫秒，已经非常快了，根本不会影响操作，但是事实上就是网络和接口请求的响应速度不可控，如果每一个交互全部都依赖接口就不可避免会带来应用交互的卡顿感。
ps：已经见过有产品因为这个问题以及其他交互和业务体验问题，导致虽然功能比竞品多，但是惨败。。。

数据库密码也放前端吗？

那么前端的业务逻辑（比如按钮可用不可用，比如各种交互细节）算不算业务逻辑呢…

看业务逻辑重不重要，前端数据不可信是重点

你：我取 500 块钱
银行：我们取钱都是 DIY 的，这边是金库，你自己进去点 500 块然后出来
你：？？？！！！

现代前端 == 客户端

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

@pureGirl 对的 看数据重要程度 ， 前端数据传到后端要校验的，所以为啥业务逻辑要放后端

@pureGirl 前端数据不可信，是因为你也不知道是用户返回有没有被篡改过，是怎么调用的，指不定人家直接调你接口呢？

客户端随便模拟的，所以关键逻辑和校验肯定是放服务端的

对啊，原本 VIP 用户才能看见 xx 内容的逻辑在后端
你现在移到前端去，用户拿油猴把你的 js 劫持一改，就变 vip 了

@Joey2022 #7 请问一下，帧同步的话，逻辑不就是放在前端吗。这种确实会产生外挂，但是还是很多游戏用。

@rimworld #2 一直写 B 端前端，我一般都是要做数据验证的，不管后端做不做二次验证

不光是能看见的问题，更是可以被篡改的问题，直接调接口的操作前面的回答已经有人说了，还有种操作是在前台写的判断甚至可以直接控制台断点把数据改掉控制代码执行的分支

我们有两个场景会把部分业务操作放到前端，一种是编辑器比如在线脑图；另一种是基于用户自身之前上传的数据的复杂统计分析，非常吃 CPU 放服务器压力太大。其实就是必须是用户自己的数据，随便怎么折腾

在游戏这一块，把数据放后端，不能完全避免防作弊。

一个强力的前端防作弊系统，比单纯的数据放后端要有效太多。游戏启动的时候，还是得加驱动，扫硬盘，各种扫。

@leoQaQ
我也是 b 端,但是跟你相反。

在少量的业务逻辑发现了大量的验证。
前端经常乱传数据。
整得我每个数据都要验证下。

@lyxxxh2 哈哈哈哈，所以喜欢你这种后端

像做微信小程序的，你修改过前端的代码，重新发布要经过微信的审核。而后端代码修改完就可以立马重新发布

后端代码自主可控，前端就不行了。前端面向客户，主要职责应该是用户信息输入，给客户提供流畅美观的使用体验

不是

后端是处理数据的，所以必须知道业务逻辑，前端是处理交互和数据展示的，并不需要完整的了解业务逻辑。这种分工是效率最大化的产物

交互敏感的放前端，数据敏感的放后端

不管前端怎么写，后端都要做一遍的，不能说前端禁用了按钮，那我后端就直接把接收到的数据存库
我的面试水平只够我遇到这种后端，放弃了

@Ayanokouji 同步是同步，验证合法性是另一回事。
其实游戏核心部分不太像传统业务逻辑开发人员前后端分的那么明确。
现在普遍做法是 帧同步世界运行时客户端自己计算，结束结算时服务端再运行一次整个战斗过程 验证合法性并且得到战斗过程数据（比如当前有任务击杀 3 个小兵）。
前端的人写完战斗系统和各种 buff 技能会编译为.dll 和.so 分别前后端调用，也有公司是前端把整个战斗服写完作为 stateless 的战斗集群，游戏服 rpc 和某个战斗实例交互。（之所以叫前端是因为这部分人编制在前端，也有从拼 UI 业务的前端深度晋升写战斗的）。

@qcbf111 感谢答疑

主要是前端"不可信", 即使一些业务在和用户的交互过程中需要进行业务处理, 后端也必须再处理一遍, 就 b/s 模型业务安全来说后端的安全性比前端的安全性高非常多, 业务数据不能依赖于前端, 否则系统将会变成万人骑

所有业务逻辑必须在后端实现一遍，而且很多业务逻辑是不希望终端用户知道的，你当然可以在前端重复实现一遍逻辑，但后端必然再实现一套，因为任何时候前端的最终用户都能跳过你的前端逻辑，直接调用后端接口。另外你要注意区分展示和业务，展示是可以变化的，业务流程的逻辑是抽象的业务流程校验。另外用户操作的数据有时候不止会影响自己，还会影响平台和第三方的利益，因此用户自己操作自己的数据的时候也必须符合系统固有的逻辑状态转换。

@chendy 算, 但是按钮可不可用可不是全由前端说了算, 首先得从后端拿到权限码前端才能识别按钮可不可用, 然后按钮后面的数据或者功能所需的接口也需要后端进行一次权限检查.

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

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

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