第五十三天

开发核心目标

基于昨日打通的网络通道，今日重点解决跨域拦截、接口路径混乱、请求转发异常三大核心问题，通过配置反向代理，统一项目接口入口，彻底适配飞书访问规范。

核心技术难点攻坚

1. 跨域问题全面排查与解决

完成内网穿透后，新的问题立刻浮现：飞书H5页面访问项目功能、机器人发起消息请求时，浏览器和服务端双重触发CORS跨域拦截。

原因很明确：飞书公网域名、前端访问地址、本地后端服务地址三者域名、端口完全不一致，属于典型的跨域场景。初期我仅通过后端添加全局跨域注解简单处理，测试后发现只能解决简单GET请求，POST预请求、飞书事件回调OPTIONS请求依旧拦截失败。

深入排查后优化解决方案：放弃简易注解配置，手动编写全局CORS配置类，放行所有飞书官方域名、适配所有请求方法、允许携带请求头和Cookie，同时单独适配飞书回调的OPTIONS预检请求，统一返回合法响应头，彻底解决跨域拦截问题。

2. 反向代理配置踩坑与优化

跨域问题解决后，接口路径混乱、重复前缀、请求转发失败的问题暴露出来。飞书平台回调地址固定，本地项目接口路径层级复杂，直接暴露原生接口存在安全隐患、路径不统一、维护困难的问题，因此搭建反向代理层至关重要。

本次采用代理服务搭建反向代理架构，过程踩坑无数：

• 初始配置路径匹配规则错误，出现接口路径重复拼接（/v1/v1），导致404访问失败；
  ​
• 未关闭长连接Keep-Alive，与飞书服务端校验规则冲突，频繁出现请求中断；
  ​
• 代理转发后丢失请求头参数，导致飞书机器人签名校验失败，无法识别合法请求。

逐一针对性优化：

1. 精准配置路径重写规则，剔除重复接口前缀，统一公网访问入口；
​
2. 禁用HTTP长连接，适配飞书服务端二次校验规则；
​
3. 配置请求头透传，完整保留飞书回调的签名、Token、设备信息，保证接口合法性校验通过；
​
4. 配置负载基础规则，规避单请求并发报错问题。

最终成功搭建稳定的反向代理架构，所有飞书请求统一经过代理层转发，接口访问规整、安全、稳定。

今日开发成果

1. 彻底解决飞书对接全场景跨域问题，适配所有请求类型；
​
2. 完成反向代理搭建与优化，统一项目接口入口，提升安全性和可维护性；
​
3. 实现飞书应用正常加载、页面正常访问、基础接口正常调用。

今日总结

今天是本次改造技术难度最高、踩坑最多的一天。跨域和反向代理看似常规配置，但对接飞书第三方平台时，存在大量专属校验规则和适配细节，稍有疏忽就会导致整体对接失败。

通过层层排查、逐行调试配置，彻底重构了项目的网络访问架构，让本地老旧CRUD项目，具备了企业级应用的访问规范。