JavaScript 进入真实业务后，很快就会碰到一个事实：前端能做的很多事情，最终都要和服务端协作完成。页面展示的数据来自接口，用户操作会触发写请求，权限判断依赖鉴权，列表要处理分页，错误提示离不开统一的错误语义。也就是说，前端并不是“拿来一个接口调一下”这么简单，而是在参与一套完整的前后端契约。
这一篇的重点，是把这种协作关系讲清楚。你需要知道：为什么接口设计会直接影响前端复杂度，状态码和错误码为什么不能混着看，分页结构为什么很能暴露系统设计习惯，鉴权为什么不是“有 token 就行”。
什么叫接口契约？
接口契约指的是前后端对请求和响应达成的明确约定，包括路径、方法、参数结构、字段命名、状态表达、错误格式和边界行为。契约清晰时，前端可以稳定消费数据，后端也知道自己的改动会影响哪里；契约模糊时，双方就会不断用“猜”和“补丁”维持协作。
很多项目之所以前端代码复杂，不是页面逻辑真的多，而是接口契约不稳定。字段一会儿叫这个、一会儿叫那个；成功响应和失败响应长得完全不同；分页有时返回总数有时不返回；权限失败和业务失败混成一团。前端最终只好写大量适配逻辑。
状态码和错误码为什么必须分层理解？
HTTP 状态码解决的是协议层语义，例如请求是否成功到达、资源是否存在、权限是否允许；业务错误码解决的是应用层语义，例如用户名已存在、库存不足、参数校验失败。两者都重要，但职责不同。
如果把它们混为一谈，前端就很难做稳定处理。比如：
- 协议层失败通常意味着网络或认证问题；
- 业务层失败则往往需要用户层面的提示和交互处理；
- 某些错误可以重试，某些不能；
- 某些错误应该跳登录，某些只该提示表单字段。
前端真正要做的是分层消费，而不是把所有失败都弹成“请求出错”。
分页结构为什么能看出接口是否好用？
列表是后台和内容系统最常见的页面形态，所以分页结构会高频出现。一个成熟的分页接口通常不仅返回数据列表，还会返回当前页、页大小、总数、是否有下一页等信息，让前端能稳定地组织表格、分页器、滚动加载和空态展示。
分页之所以重要，是因为它暴露了协作质量。结构清晰时，前端列表逻辑可以非常稳；结构混乱时，分页状态往往散落在各处，改筛选、跳页、重置条件时就容易出错。
联调为什么总会把接口问题放大？
因为前后端在本地各自开发时，很多问题还处在“各自合理”的状态，真正联到一起时才会暴露冲突。例如前端默认某字段一定返回，后端却在空值时省略；前端以为翻页参数是 page 和 pageSize，后端却按 current 和 size 接；前端按 HTTP 状态码判断登录失效，后端却统一返回 200 再给业务码。
所以联调阶段真正重要的不是“赶快把页面调通”，而是借这个阶段把接口契约收敛下来。越早推动统一，后面前端业务代码里的补丁就越少。
鉴权流程为什么不能只看 token 存哪儿？
很多人一谈鉴权，就只关注“token 放 cookie 还是本地存储”。这当然是其中一部分，但真正完整的鉴权流程要看更多环节：
- 登录成功后身份信息如何下发；
- 请求时身份如何附带；
- 失效时怎样处理；
- 刷新页面后如何恢复会话；
- 权限不足是前端拦还是服务端拒；
- 多标签页、退出登录和过期刷新如何协同。
这说明鉴权是前后端共同维护的一条链路，而不是前端自己持有一个字符串就结束。
复杂业务里最容易忽略哪几类协作边界？
除了最显眼的登录和列表，复杂业务里还有几类边界特别容易被低估：
- 表单提交失败后，哪些字段级错误由后端返回、哪些由前端本地校验；
- 上传、导出、长任务轮询这类接口，状态推进由谁主导；
- 乐观更新后失败回滚时，前端是否有足够信息恢复现场；
- 权限按钮是否只靠前端隐藏，还是服务端也做强校验。
这些问题如果不提前约定，前端最后往往只能在组件里堆很多临时兼容逻辑。
前端在协作中最该主动推动什么？
成熟的前端协作，不只是被动适配接口。很多时候，前端应该主动推动几个方面：
- 字段命名和结构保持一致；
- 错误响应格式统一；
- 分页和筛选参数有清晰规范；
- 鉴权失败和权限不足有明确区分；
- 空值、默认值和边界行为提前约定。
这样做不是“越权设计后端”，而是在减少整个系统的联调成本。
一个成熟的前端消费层通常会怎么分层？
为了避免请求逻辑和业务页面紧耦合，成熟项目通常会把接口消费分成几层：
- 请求层：统一处理基础请求、超时、鉴权附带和协议层错误；
- 适配层：把后端返回的字段结构整理成前端更稳定的数据形态；
- 页面层：只关注加载态、空态、交互状态和业务展示。
这种分层的价值在于，后端接口偶尔波动时，不需要每个页面都跟着改；同时页面代码也不会被状态码、错误码和字段兼容细节淹没。
常见误区
这一章常见问题包括：
- 认为前端只负责调用接口，不需要关心契约设计；
- 把状态码和业务码混在一起处理；
- 分页结构设计随意，列表逻辑越来越碎；
- 只关注 token 存储，不关注完整鉴权链路；
- 碰到后端返回不一致就直接在前端加兼容补丁，不推动收敛。
和后续章节的关系
下一篇我们会进入 AST 与自动化，看 JavaScript 除了写业务之外如何参与工具和代码改造。这里的服务端协作，则是 JavaScript 进入业务系统最关键的一条现实主线。
写在最后
真正成熟的前端，不是把接口请求包起来就结束，而是能看懂并推动更稳定的协作边界。接口契约、错误分层、分页结构和鉴权流程看似琐碎，实际上直接决定前端代码会不会越写越乱。下一篇我们把视角从业务协作再往外扩，进入 JavaScript 的自动化能力。