2. 客户机与服务器的区别是什么

刚开始写代码的人常常卡在一句话上：这段逻辑到底该写在客户端还是服务端？别人说「客户机发请求、服务器给响应」，可真到动手又分不清谁在等谁。这篇不讲抽象定义，直接教你用「谁主动、谁常驻、谁手里有别人看不到的数据」三条线索判断，再给一份看报错时的排查顺序，顺带说清哪些场景这套分法不适用。

刚开始写代码的人常常卡在一句话上：这段逻辑到底该写在客户端还是服务端？别人说「客户机发请求、服务器给响应」，听起来很顺，可真到动手又分不清谁在等谁、谁该保管什么。这篇不讲抽象定义，直接给你三条能立刻用上的判断线索，再配一份看报错时的排查顺序，顺带说清哪些场景这套分法根本不适用。

先换个思路：别把客户机当成「弱的一方」，也别把服务器当成「某台大机器」。它们只是两种角色，一种主动开口，一种等着被叫。同一台笔记本，装上浏览器就是客户机，跑起本地服务又成了服务器。搞清角色，比记住定义有用得多。

先记住两个角色，不背定义

客户机

主动发起请求的一方，谁先开口谁就是它

服务器

长期在线、等着被请求、收到后干活再回话的一方

角色切换

同一台机器可以同时是两种角色，看它当下在做什么

常见误解

「服务器」不代表一台专门的硬件，它首先是一个角色

• 客户机是主动发起请求的一方，服务器是等着被请求的一方：谁先开口，谁就是客户机
• 服务器通常长期在线、地址相对固定、一次要应付很多个客户机；客户机可能开开关关，地址还可能变
• 同一台机器可以两种角色都当：浏览器是客户机，本机跑的服务也可能被别人当服务器用
• 不要把「服务器」理解成一台大机器，它更多是一个角色，一台上网本也能当服务器

三条线索，一眼分辨谁是谁

光靠「客户端」「服务端」这两个词，新手很容易绕晕。更实在的办法是拿三条线索去套：看谁发起、看谁保管别人看不到的数据、看谁在干等。三条都对上，基本不会判错；如果三条互相打架，那就用下面那张表里的优先级来定。

判断口诀可以简化成一句：能自己算出来的放客户机，必须别人告诉你的放服务器。比如「这个按钮点了变灰」客户机自己就能决定；「这个用户有没有权限下单」就得问服务器，因为客户机拿不到全站权限表。

真的动手写：这段逻辑放哪边

1. 先给逻辑归类问自己：这段判断依赖用户本地的输入，还是依赖全站数据？只依赖本地输入的，可以先写在客户机；依赖全站或他人数据的，写到服务器。
2. 把校验拆成两层客户机做「体验层校验」，比如输入框格式提示、按钮立刻置灰；服务器做「真实层校验」，比如金额、权限、库存。两层都要有，缺一层都会出问题。
3. 检查请求里带了什么客户机发出去的请求字段，等于把这些内容公开给用户。凭证、密钥这类不该给看的，一个都不要塞进去。
4. 数一数来回次数能在一次请求里带回去的数据，别拆成三次去取。来回越多越慢，也越容易在弱网下出问题。
5. 验证方式打开开发者工具，看请求发出后返回了什么；再去服务器日志确认它收到的字段跟你发的是否一致，两头对上才算通。

要提醒一句：客户机上的校验只是体验，不是安全。用户能改自己发出去的请求，所以真正决定「能不能做」的判断，永远留在服务器那一侧。这条想通了，很多权限漏洞就自然避开了。

出问题时按这个顺序看

新手最容易犯的错是一上来就盯着服务端日志，其实该先确认请求有没有真的发出去。下面这个顺序从发起侧往接收侧走，能少走很多弯路。中途如果分不清哪边的问题，就用最笨的办法：让客户机只发一条最短的测试请求，接收方只回一句固定内容，通了再往上加。

• 先确认发起方有没有真的发出去：打开开发者工具看请求是否发出、状态码是多少，再谈别的
• 再确认接收方是否在跑：服务没启动、端口没监听时，客户机看到的往往是被拒绝或连不上，而不是报错详情
• 再看两头说的字段是否一致：名字拼写、大小写、嵌套层级不一致，是新手最常见的「明明发过去了却拿不到」
• 最后才看业务逻辑：前三条都通了还不对，再回去查服务端里的判断条件

这套分法什么时候不适用

客户机与服务器这套分法很通用，但不是万能的。它默认存在「请求—响应」这样一个来回，一旦场景里没有明确的先后顺序，硬套反而更乱。判断标准很简单：如果找不到谁在主动开口、谁在等着被叫，那就不该用这套框架去想问题。

• 静态页面、纯本地小工具、单机脚本里，前后脚都在同一台机器上跑，硬分客户机服务器没意义
• 用无服务器函数或托管平台时，机器细节被平台藏起来了，你只需要关心「请求进来、结果返回」
• 点对点传输、消息队列这类场景里没有明显的请求响应顺序，用发布订阅的思路理解更合适

遇到上面这些情况，别纠结怎么给角色命名，先想清楚数据从哪来、到哪去、中间经过谁，问题往往就清楚了。想看更细的技术判断标准，可以到站内资料库对照当时的整理版本，别记死某一篇的结论。