客户端与服务器端有什么区别

刚上手写项目的人常卡在一个地方：这段逻辑到底该写在浏览器里，还是放在服务器上？写反了要么Key暴露，要么页面卡死。这篇不讲协议细节，只给一套判断顺序——按职责、按能力、按信任边界把两边分工理清，再给一份常见场景的对照表和自查清单。

刚上手写项目的人，最常卡在一个地方：这段逻辑到底该写在浏览器里，还是放到服务器上？写反了的后果很具体——要么把密钥直接暴露在页面上，要么让页面卡死等一个本该后台跑的活。这篇不讲协议分层，只给一套能照着走的判断顺序：先看职责，再看信任边界，最后按场景对号入座，接不上时还有一套排查链路。

先说清一件事：客户端和服务器端不是「谁更重要」的关系，而是分工关系。客户端离用户近，负责让人看得见、点得动；服务器端离数据近，负责让规则算得准、管得住。两边各干各的，交界处靠请求和响应传递。想快速判断一个功能放哪边，记住一句话就够了——只影响当前这台设备的，放客户端；影响别人、影响钱、影响长期数据的，放服务器。

两边各自在干什么：一句话分清楚

客户端

跟人打交道的部分：界面渲染、点击响应、输入框即时提示、当前页面的临时状态，跑在用户的设备上。

服务器端

跟数据和规则打交道的部分：登录鉴权、额度计算、写数据库、给多个用户共享同一份状态。

交界处

客户端发请求、服务器端回结果，所有跨设备的共享信息都得走这条路。

判断口诀前面已经给了，落到实操上有三条线：只影响当前这台设备的，放客户端；影响别人、影响钱、影响长期数据的，放服务器。同一个功能两边都写一遍其实很常见，比如表单校验——客户端做一次是为了让用户马上看到红色提示，服务器端再做一次是因为前端的校验可以被绕过。这叫双重校验，不是重复劳动。

• 界面动画、按钮禁用状态、输入框字数提示：客户端，改不改都不影响别人
• 登录后能不能看到某个页面：服务器端说了算，前端隐藏按钮只是体验
• 把一段文本存进数据库下次还能看到：服务器端，客户端刷新就没了
• 批量给一批用户发通知：服务器端，没人盯着屏幕也得跑完

信任边界：哪些东西绝对不能放客户端

客户端的一切都在用户手里：代码能看，请求能抓包，变量能改。所以有一类东西放进前端等于直接公开——长期凭证。API Key、数据库口令、支付签名密钥这类东西，一旦出现在浏览器能加载的文件里，就默认已经泄露了。正确做法是让客户端请求自己的服务器，由服务器端拿着密钥去调外部服务。

涉及钱的逻辑要特别强调一遍：客户端可以算一遍让界面马上出数，但服务器端必须再算一遍，并且永远以服务器端的结果为准。前端算出来的那个数只是预告，不是承诺。权限判断同理，前端把按钮藏起来只是体验优化，真正的拦截必须发生在服务器端，否则改一行代码就绕过去了。

按场景对号入座：常见需求该放哪边

光记原则容易忘，按场景对照更快。下面这张表把新手最常遇到的几类需求拆开，每一行都说明两边各自负责什么，照着填就不会写反。

每行都遵循同一个规律：客户端那一列只跟「当前这个人、当前这块屏」有关，服务器端那一列都涉及共享状态或不可绕过的规则。有个例外要单独说——强离线场景，比如现场作业没有网络，客户端需要先把数据落到本地存储，联网后再同步给服务器。这种情况下两边都要有状态，同步策略就得额外设计，不能简单照表搬。

接不上时怎么排：先定边界再查链路

写完发现功能不工作，新手容易两边乱翻。第一步其实不是看代码，而是先问一句：报错出现在浏览器控制台，还是服务器端日志里？这两处位置完全不同，先分清在哪一侧，能省掉一大半瞎找。

1. 确认请求有没有发出去打开浏览器的网络面板，看点击后有没有对应的请求记录。没有就说明问题在客户端触发逻辑。
2. 看请求长什么样检查请求地址、方法、携带的数据是否正确。最常见的坑是参数名写错或漏传，服务器端收到的跟你想的不一样。
3. 确认服务器端有没有收到去服务器端日志里找这次请求。日志里没记录，说明卡在中间链路或根本没到；有记录但要继续往下看。
4. 看服务器端返回什么状态码和响应体是判断依据。返回错误就查服务器端的处理逻辑，返回正常但界面不对，问题就回到客户端渲染。
5. 看客户端怎么处理结果拿到响应后是解析出错、字段名对不上，还是状态没更新，逐项核对。

这套顺序的价值在于每一步都有明确的判断点，不用凭感觉猜。要提醒的是它只适用于「数据接不上」的问题——纯粹样式错位、动画掉帧这类跟网络无关的毛病，直接在前端查就行，跑这套流程是浪费时间。