lovife
2ff17cd0c9
用户决定：后端不再对外发静态文件，学生端 H5 交给网关。两者**仍然同源**
（微信只给一个授权回调域名；H5 的接口地址取自 location.origin），
所以前端业务代码、微信后台、application-dev.yml 的 h5-base-url 都不用改。
后端
- 删掉 dev/test/prod 三份 profile 里的 spring.web.resources.static-locations
- 主配置加 spring.web.resources.add-mappings=false —— 用开关而不是"指到空目录"：
后者会连带启用 Spring Boot 的默认位置（classpath:/static 等），谁丢个文件进去就悄悄对外可见
- StaticCacheHeaderFilter → ApiNoStoreFilter，只剩 /api/** 的 no-store
（静态资源的缓存策略整体归 nginx，避免"改一处漏一处"）
- 补 NoHandlerFoundException → 404：关掉静态映射后未匹配路径不再经过
ResourceHttpRequestHandler，抛的是 NoHandlerFoundException，只处理
NoResourceFoundException 时访问 / 会变成 500「系统繁忙」并刷 ERROR 日志
deploy
- 新增 xt-nginx（80）：发 frontend-mp/dist/build/h5 + /api 反代 8080（host.docker.internal，
Linux 靠 extra_hosts host-gateway），端口与产物目录走 .env 的 H5_PORT/H5_DIR
- 三条"删了就会出事"的都已带上理由：client_max_body_size 50m（默认 1m，超了回 413
而后端日志一个字都没有）、/assets 的 immutable 与 *.html 的 no-cache（§一·十 那个
"发版后学生看到旧页面"的坑）、健康检查写 127.0.0.1（容器里 localhost 先解析到 IPv6，
nginx 只听 IPv4 → 永远 starting 而首页是好的）
CI 与文档
- CI：学生端 H5 构建从"e2e 的输入"改为编译检查，不再留 artifact（e2e 不消费它）
- 同步 AGENTS.md / README.md / docs/09（启动步骤、CI 表、发布注意、排障表）/ docs/11
- 交接摘要新增 §一·四十三（含理由、验证数字、要人工做的一步与环境限制）
验证
- mvn clean package 通过（必须 clean：删掉的旧类会留在 target/classes 被组件扫描）
- 后端直连：/ 与 /assets/* → 404（{"code":40001,"msg":"接口不存在"}）、
/api/.../captcha → 200 + no-store、/doc.html → 302→200、/v3/api-docs 与 /actuator/health → 200
- 经 nginx(80)：首页 200 + no-cache、/assets/*.js 200 + immutable、/nope.js 404（无回退）、
/api 200 + no-store、gzip 生效；2MB multipart 上传 → 401（与直连一致 ⇒ 未踩 1m 的坑）、
55MB → 413
- e2e（XT_BASE=http://localhost，全程走 nginx）：e2e-m0.py 37/37、e2e-m3-h5-auth.py 24/24、
e2e-m2-scope.py 38/38
- verify-all.py --quick 6/6；check-test-profile.py：test profile 仍能起来
43 lines
1.8 KiB
TypeScript
43 lines
1.8 KiB
TypeScript
import { defineConfig } from "vite";
|
||
import uni from "@dcloudio/vite-plugin-uni";
|
||
|
||
/**
|
||
* 学生端（uni-app）的 vite 配置。
|
||
*
|
||
* ## ⚠️ 这里加了一个 dev proxy，解决一个真实的开发痛点
|
||
*
|
||
* H5 **没有独立 dev server** 是之前的状态：`src/config/index.ts` 里
|
||
* `API_BASE_URL = location.origin`，而 vite dev server 不代理 `/api`，
|
||
* 于是 `pnpm dev:h5`（另一个端口）打不到后端 8080 上的接口 ——
|
||
* 只能 `pnpm build:h5` 再访问**构建产物**（当时由后端 8080 托管，
|
||
* 2026-10 起改由 nginx 托管，见 deploy/nginx/xt.conf）。
|
||
*
|
||
* 后果不只是"麻烦一点"：**改一行要等一次完整构建**，而学生端正是改得最多的地方
|
||
* （表单、上传、核验页），反馈慢会直接改变开发方式 ——
|
||
* 人会倾向"一次改一堆再构建"，而那时候出问题已经分不清是哪一处引起的。
|
||
*
|
||
* 所以这里补两件事（**缺一不可**）：
|
||
* ① 本文件的 `server.proxy`：把 `/api` 转发到后端；
|
||
* ② `src/config/index.ts` 里让 `API_BASE_URL` 优先取 `VITE_API_BASE` ——
|
||
* 否则它仍然是 `location.origin`（= dev server 自己），代理配得再对也没用。
|
||
*
|
||
* ## ⚠️ 微信小程序端不受影响
|
||
*
|
||
* 小程序的请求不走 vite（它在微信开发者工具里跑），而且微信的
|
||
* **request 合法域名是固定白名单**，配不了 localhost —— 所以那边照旧。
|
||
* 由 `#ifdef H5` 条件编译保证。
|
||
*/
|
||
export default defineConfig({
|
||
plugins: [uni()],
|
||
server: {
|
||
port: 5174,
|
||
proxy: {
|
||
// 与 frontend-pc 同一做法：dev server 上的 /api 转发到本机后端
|
||
"/api": {
|
||
target: "http://localhost:8080",
|
||
changeOrigin: true,
|
||
},
|
||
},
|
||
},
|
||
});
|