全栈联调踩坑记：我在银行信贷系统里怎么让前后端少吵架

全栈联调踩坑记：我在银行信贷系统里怎么让前后端少吵架

全栈开发这事儿，听起来光鲜，实际干起来全是坑。我之前在兰屿星奇做那个银行信贷系统时，前后端联调差点把团队心态搞崩。五天的工期硬是磨成半个月，最后靠几招笨办法，硬是把时间压到了一天半。这篇文没啥高深理论，全是真金白银砸出来的教训。

架构这档子事

一开始我们也想搞点花哨的，什么微服务、容器化，但在信贷系统这种业务逻辑复杂的场景下，先分清楚谁干啥更重要。我们最终定了 React + TypeScript 在前台撑门面，后台用 Django 处理那些烦人的金融计算和数据校验。

我后来发现，只要把响应格式统一封装成 success/data/message 结构，前端不用再猜字段名，后端也不用反复改返回体——连 Swagger 文档都省了一半力气。模块划分上也没搞那么细，就把信贷申请、审批、放款拆成独立模块，耦合度稍微低了点，各自为战也方便。

接口规范：少吵架的秘密

接口设计这东西，说穿了就是给未来挖坑还是铺路。我们没用啥复杂的 graphql，就老老实实 RESTful。每次开会前，前后端一起把字段定义清楚，写在 Swagger 里。有个教训挺深刻的：有一次后端偷偷加了个字段没通知前端，结果前端渲染直接炸了，排查花了两天。

ApiResponse 结构很简单：
- success: boolean，告诉前端有没有挂
- data: 具体数据
- message: 出错了说人话
- timestamp: 排查问题时用来对表

联调流程：Mock 是救命稻草

第一次联调卡在 OPTIONS 预检失败，查了40分钟才发现 Express 默认没开 credentials。后来我们直接把 cors 配置写进 docker-compose.yml 的 env 里，再也没人动过它。

为了解决等待后端接口的问题，我们前端先搞 Mock。用的 MSW（Mock Service Worker），在开发环境拦截请求返回假数据。这样前端不用盯着后端屁股后面催进度。

import { http, HttpResponse } from 'msw';
import { setupServer } from 'msw/node';

const handlers = [
  http.get('/api/users', () => {
    return HttpResponse.json([
      { id: 1, name: '张三' },
      { id: 2, name: '李四' }
    ]);
  })
];

export const server = setupServer(...handlers);

后端写完接口后，我会先跑一遍自动化测试验证基础功能，避免低级错误带到联调环节。Linux 或 macOS 下可以用 npm run dev & npm test 同时启动，Windows 用户建议用 concurrently 或者分开跑，别硬来。

至于调试工具，Postman 和 Insomnia 都行，关键是要把测试集合共享给团队，别各玩各的。

那些让人头秃的问题

CORS 跨域是个经典问题，配置好 Origin 和 Credentials 基本能搞定大半。数据类型不一致更恶心，比如后端传 "123" 字符串，前端当数字用，运算结果全是 NaN。后来我们强制要求后端返回严格的 JSON 类型，前端用 TypeScript 严格校验，才消停。

版本管理也得盯着。老接口加了个 status 字段，但保留了原来所有字段和 HTTP 状态码，前端不发版也能跑，这就是所谓的向后兼容。要是直接删字段，前端页面能给你白屏一片。变更历史用 Changelog 记清楚，别到时候扯皮。

性能优化：上线前的最后一搏

联调完了别急着发版，性能这块得再过一遍。请求合并挺实用，几个小接口拼成一个批量接口，减少网络往返次数。缓存策略按场景来，热点数据放 CDN，不常变的配置放浏览器本地。

懒加载现在几乎是标配，路由级和组件级都搞上，首屏速度能快不少。代码分割按功能模块切，用户用到哪块下哪块。上线那天，我盯着 Lighthouse 分数看了三分钟。没敢截图发群。

团队协作：技术之外

说白了，技术问题往往是人情问题。环境配置标准化，新人来了能直接跑起来，别让人家花一天时间配环境。分支管理用 Git Flow，别乱 merge。定期拉上前后端对齐进度，别等到联调那天才发现两边理解完全岔劈。

文档写清楚，尤其是那些不在代码里的隐性逻辑。这些看似废话，真出了事都能救命。

干了这么多年全栈，我越来越觉得，联调不是技术活，是沟通活。少点主观臆断，多点契约精神，团队能少掉很多头发。