客户端与服务器端有什么区别 从大小、配置、服务对象

写代码时经常有人问：这段逻辑该放客户端还是服务器端？凭感觉选，后面不是 Key 泄露就是请求绕远路。这篇不讲协议也不讲怎么配客户端，只给一套判断顺序：先看体积能不能进包，再看配置归谁管，最后看服务对象是谁，三步下来基本能定。

写代码时经常有人问：这段逻辑该放客户端还是服务器端？凭感觉选，后面不是 Key 泄露就是请求绕远路。这个问题其实不该靠直觉，而是有一套固定的判断顺序：先看体积能不能进包，再看配置归谁管，最后看服务对象是谁。三步走完，落点基本就定了。

这篇不讲协议细节，也不讲客户端怎么打包，只给一套开发者能照着走的对照方法。下面按体积、配置、服务对象三个角度逐条拆，每一节都配了判断标准和可执行动作，看完可以直接拿自己的项目过一遍。

先看体积：什么东西能塞进客户端

客户端要分发到用户机器或浏览器，包体积、启动耗时、内存占用都直接影响体验，能砍就砍；服务器端包大一点无所谓，但要算清单机内存和实例数。判断标准很直接：这段代码依赖的数据量是不是随用户增长而增长？是就放服务端，前端只留展示层。

• 把当前包里最大的几个依赖列出来，逐个问它是不是必须在前端运行
• 依赖的数据集如果会随用户量变大自然膨胀，展示层放前端、计算层放服务端
• 纯离线的桌面工具、本地跑的小模型，前端体积不是瓶颈，硬拆反而增加复杂度
• 服务器端虽然包体积宽松，但内存和实例数是按量算的，别把整库数据直接常驻进程

# 打包产物看一眼谁最大，作为拆分起点
ls -lh dist/assets | sort -k5 -h | tail -n 10

再看配置：哪些参数和密钥不能放客户端

凡是长期有效的密钥、管理口令、数据库连接串，默认都归服务器端，客户端只拿短期凭证或自己的登录态。配置来源可以分两类：用户自己的偏好设置可以放客户端本地；影响计费、权限、额度的开关必须在服务端下发。

长期密钥

有效期长、泄露后影响面大，一律留在服务端，前端不接触

短期凭证

有明确过期时间、可随时吊销的令牌，可以下发给客户端

用户偏好

主题、语言、布局这类只影响自己的设置，放本地没问题

计费与权限开关

决定谁能用、用多少的开关，必须服务端说了算

完全不连远端服务的本地工具谈不上密钥托管，按本地文件处理就行，这一条不适用。可执行动作：把项目里的配置项过一遍，凡是被前端代码或打包产物读到的，逐个确认是不是敏感值；拿不准就去站内核对计费与鉴权口径，必要时到 去站内 核对当时的数字。

最后看服务对象：给一个人用还是给一群人用

服务对象是单个用户时，逻辑可以贴近客户端，省一次往返；服务对象是多用户共享的资源，比如配额、缓存、排队、限流，就必须收敛到服务器端统一算。判断标准：同一份状态会不会被两个人同时改？会就放服务端，客户端只发意图。

多人但互不影响的只读场景，比如各查各的文档，放哪边都行，按维护成本选。可执行动作：画出一次请求的路径，标出状态存在哪、谁改它；如果状态分散在多处，先合并再决定落点，别一边前端缓存一边后端计数。

定不下来时的排查顺序与落地清单

1. 第一步 走体积列出包里最大的依赖，凡是随用户增长而膨胀的数据处理，移到服务端，验证方式是前端只保留渲染逻辑后包体积是否下降。
2. 第二步 走配置扫描所有被前端读到的配置项，涉及密钥、计费、权限的上移服务端，验证方式是构建产物里搜不到敏感串。
3. 第三步 走服务对象标出会被多人同时改的状态，全部收敛到服务端，验证方式是并发改同一份数据时不出现互相覆盖。
4. 第四步 跑落地清单检查请求路径有没有多绕一跳、失败时谁来重试、日志能不能复原这次调用、超时和并发怎么设。
5. 第五步 回站内对数字上线后回到站内用量与价格页对一遍当时的数字，确认拆分没有把成本结构改坏。

三步都指向服务端就别犹豫，三步都不指向就留在客户端。真正容易出问题的是那种一边沾一点的设计：密钥藏在客户端、计费逻辑散在两边，这种最该先统一落点再谈优化。