关于前后端接口联调的问题讨论

挺好的，可以缩短开发周期，都写完再联调就行

没有问题呀，一般都这样，而且后端都是先写 idl 生成接口文档和模板代码

但有个磨合的过程，成熟的项目确实这样很快。但不能去掉联调和测试这个环节

我们就是这样，有排联调时间，基本不需要联调。

说下我们公司的方案：
背景：前端用的 TypeScript React ，后端是 Spring
后端使用 springdoc 插件生成 swagger scheme 并且经可能的写上注释
前端使用 swagger-typescript-api 插件根据后端的 swagger scheme 生成接口文件，然后直接调用即可
这样在后端有接口变动的时候只要前端重新生成并通过 TypeScript 类型检查基本上就没啥问题

太理想了。

根本不操心这个问题，前端后端测试全包了

这就是正常的开发流程吧，文档先行。。。

我觉得设计接口，mock 数据都是没问题的，是可以提升开发效率的，但要说这就能不联调就有点过了，只能说可以减少很多联调过程中的问题。
怎么保证文档设计完，mock 的数据直到提测过程完全不会变动的？后端提测时的接口质量怎么保证？
就算不联调，测试团队也需要进行集成测试，只不过是把问题都堆给测试阶段，各种问题再返回开发去排查效率更低。

我喜欢这样的, 起码出了问题的时候 找得到人背锅.

理想的情况是全栈，各人按业务模块划分；其次是搞个 mock 接口服务，后端提前定义好接口的出入参，前端直接调用 mock 服务开发，不需要手写 mock 的数据；最后才是 op 说的后端先给文档，前后端再根据文档开发。
不管是 mock 服务，还是文档，都难免遇到需求、设计变更导致的文档变更问题，这时就需要维护文档，并将文档变化实时通知到关联开发人员，最好还需要记录变更历史（谁什么时候因为什么导致了什么变更），避免甩锅。

根据文档，也就是按照约定来进行开发是对的。至于这个过程遇到的问题，解决问题就好。没有什么模式是完美的，是不会出任何问题问题的。只要是人干的事，就必然会有各种稀奇古怪的问题。

可以让后端接入 swagger/openapi 规范，先出接口定义，前端根据定义生成接口文档和 axios 请求，也是一种凭据
这个是根据 swagger/openapi 规范生成的接口文档，https://github.com/rookie-luochao/openapi-ui