wangyizhe/his

Fork 0

Files

华佗 7dc54278ed docs(bug): 诸葛亮分析报告 Bug #724

2026-06-13 01:24:08 +08:00

6.6 KiB

Raw Blame History

Bug #724 诸葛亮分析报告

文档类型: Bug分析 分析时间: 2026-06-13 01:24:08 分析模型: mimo-v2.5 (LLM深度分析)

基本信息

Bug #: 724
标题: 【合理用药】模块下的功能卡片打开都会出现报错
模块: 手术麻醉管理
提出人: 王栩坤

Now I have a clear picture. Let me trace the full request flow and output my analysis.

一、Bug 理解

禅道原文引用

Bug 标题: 【合理用药】模块下的功能卡片打开都会出现报错

重现步骤: 登录内科医生1的账号 doctor1 / 123456 → 打开合理用药 → 点击合理用药下面的模块

期望结果: 不会出现报错，能够正常进入该模块下的页面

附图关键信息

截图中红色错误横幅：

No static resource healthlink-his/api/v1/antibiotic/statistics for request '/healthlink-his/healthlink-his/api/v1/antibiotic/statistics'.

左侧导航栏"合理用药"展开，包含四个子模块：抗菌药物规则、药物相互作用、审核日志、合理用药统计。四个统计卡片全部为 0，表格显示"暂无数据"。所有模块页面都会出现相同报错。

综合总结

用户登录医生账号后，打开"合理用药"模块下的所有子页面（抗菌药物规则、药物相互作用、审核日志、合理用药统计），页面顶部均出现红色错误提示。错误信息显示请求路径中 /healthlink-his 出现了两次，导致 Spring Boot 无法匹配到任何 Controller 端点，所有合理用药相关 API 请求全部失败。

二、根因分析

错误路径解剖

浏览器请求: /healthlink-his/healthlink-his/api/v1/antibiotic/statistics
                 ↑ 第一次                    ↑ Spring Boot context-path

Spring Boot 收到请求后：

去除 context-path /healthlink-his → 剩余路径：/healthlink-his/api/v1/antibiotic/statistics
匹配 Controller：AntibioticController 的 @RequestMapping("/api/v1/antibiotic") → 无法匹配（路径多了一层 /healthlink-his）
Spring Boot 退化为静态资源查找 → 找不到 → 返回 404 错误

请求链路追踪

前端 API 调用:
  request.js → baseURL = import.meta.env.VITE_APP_BASE_API
  api/antibiotic/index.js → url = '/api/v1/antibiotic/statistics'
  最终 URL = ${VITE_APP_BASE_API}/api/v1/antibiotic/statistics

错误路径 = /healthlink-his/healthlink-his/api/v1/antibiotic/statistics

反推得出：VITE_APP_BASE_API 在实际部署环境中被设置为 /healthlink-his（或类似的包含 context-path 的值），而非代码仓库中定义的 /prd-api 或 /dev-api。

根因结论

上下文路径 /healthlink-his 被重复叠加了两次。 可能的触发场景：

层	配置	效果
`VITE_APP_BASE_API`（实际部署值）	`/healthlink-his`（异常值，代码仓库中为 `/prd-api`）	前端发送 `/healthlink-his/api/v1/...`
Nginx 代理	`location /healthlink-his/ { proxy_pass http://backend/healthlink-his/; }`	转发后路径变为 `/healthlink-his/api/v1/...`
Spring Boot context-path	`context-path: /healthlink-his`	去除一次后剩余 `/healthlink-his/api/v1/...` → 无法匹配

核心矛盾：前端 API 路径 /api/v1/... 是正确的相对路径，但 VITE_APP_BASE_API 环境变量在部署时被设置为了 /healthlink-his，与 Spring Boot 的 context-path 冲突，导致路径叠加。

涉及文件

文件	作用	是否需要修改
`healthlink-his-ui/src/utils/request.js:56`	`baseURL: import.meta.env.VITE_APP_BASE_API`	✅ 需确认部署时的值
`healthlink-his-ui/src/api/antibiotic/index.js`	抗菌药物 API 定义（`/api/v1/antibiotic/...`）	❌ 路径正确
`healthlink-his-ui/src/api/rationaldrug.js`	合理用药 API 定义（`/api/v1/rational-drug/...`）	❌ 路径正确
`healthlink-his-server/.../application.yml:20`	`context-path: /healthlink-his`	❌ 后端正确
`deploy/nginx-healthlink-his.conf`	Nginx 代理配置	✅ 需确认实际部署版本

三、修复方案

方案 1：修复部署环境的 `VITE_APP_BASE_API`（推荐，最小改动）

问题本质：部署环境使用了错误的 VITE_APP_BASE_API 值。

修复：确保部署时使用正确的环境文件：

# 生产环境部署命令
cd healthlink-his-ui
npm run build -- --mode prod

确保 .env.prod 中的值为：

VITE_APP_BASE_API = '/prd-api'

对应的 Nginx 配置（deploy/nginx-healthlink-his.conf）：

location /prd-api/ {
    proxy_pass http://127.0.0.1:18082/healthlink-his/;
    ...
}

方案 2：如果部署环境必须使用 `/healthlink-his` 作为前端路径

如果实际部署环境中前端通过 http://server/healthlink-his/ 访问，Nginx 也需要相应调整：

# 方案 A：Nginx 不在 proxy_pass 中添加 context-path（让 Spring Boot 处理）
location /healthlink-his/api/ {
    proxy_pass http://127.0.0.1:18082;  # 注意：无尾部路径
    ...
}

# 方案 B：前端 API 路径不包含 context-path
# VITE_APP_BASE_API = ''（空字符串），前端请求 /api/v1/...
location /api/ {
    proxy_pass http://127.0.0.1:18082/healthlink-his;
    ...
}

方案 3：代码层面的防御性修复（可选）

在 request.js 中添加 URL 校验，防止 context-path 重复：

// request.js 中 axios 实例创建后
service.interceptors.request.use(config => {
  // 防止 baseURL 包含后端 context-path 导致重复
  if (config.baseURL && config.baseURL.includes('/healthlink-his')) {
    console.warn('[WARN] VITE_APP_BASE_API 包含 /healthlink-his，可能导致路径重复！')
  }
  // ...existing code
})

四、路由决策

FIXER: guanyu（后端）+ zhaoyun（前端）联合排查，优先 zhaoyun

REASON: 本 Bug 的根因是部署配置问题而非代码缺陷。需要：

zhaoyun 确认实际部署环境的 VITE_APP_BASE_API 值，检查前端 .env 文件和构建命令是否正确
guanyu 确认后端 Spring Boot context-path 与 Nginx 代理规则的匹配关系
修复的核心是对齐前端 baseURL 与 Nginx 代理规则，确保 /healthlink-his 不被叠加两次

优先级：zhaoyun 先检查 .env.prod 和实际构建配置 → guanyu 验证 Nginx 配置 → 联合确认修复

路由决策

FIXER_ID: guanyu
修复 Agent: guanyu（后端）
原因: LLM 分析决策

⚠️ 修复人员请先验证以上分析是否正确，再执行修复。

6.6 KiB Raw Blame History Unescape Escape