2026-04-02 11:22:17 +08:00
|
|
|
|
# 技术指南
|
|
|
|
|
|
|
|
|
|
|
|
更新时间：2026-03-25
|
|
|
|
|
|
|
|
|
|
|
|
本文件不再承载泛化培训内容，改为当前项目的技术入口索引。
|
|
|
|
|
|
|
|
|
|
|
|
## 1. 先读什么
|
|
|
|
|
|
|
|
|
|
|
|
建议阅读顺序：
|
|
|
|
|
|
|
|
|
|
|
|
1. `README.md`
|
|
|
|
|
|
2. `docs/status/REAL_PROJECT_STATUS.md`
|
|
|
|
|
|
3. `docs/team/QUALITY_STANDARD.md`
|
|
|
|
|
|
4. `docs/team/PRODUCTION_CHECKLIST.md`
|
|
|
|
|
|
5. `docs/team/PROJECT_EXPERIENCE_SUMMARY.md`
|
|
|
|
|
|
|
|
|
|
|
|
## 2. 当前项目最重要的真实结论
|
|
|
|
|
|
|
|
|
|
|
|
- 主验收路径是 `cd frontend/admin && npm.cmd run e2e:full:win`
|
|
|
|
|
|
- 当前闭环的是浏览器级真实 E2E，不是完整 OS 级自动化
|
|
|
|
|
|
- `smoke` 仅用于诊断，不是运行时依赖
|
|
|
|
|
|
- 非测试代码中的 `panic`、fake success、mock runtime provider 都应视为缺陷
|
|
|
|
|
|
|
|
|
|
|
|
## 3. 常用命令
|
|
|
|
|
|
|
|
|
|
|
|
### 后端
|
|
|
|
|
|
|
|
|
|
|
|
```powershell
|
|
|
|
|
|
go test ./... -count=1
|
|
|
|
|
|
go vet ./...
|
|
|
|
|
|
go build ./cmd/server
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 前端
|
|
|
|
|
|
|
|
|
|
|
|
```powershell
|
|
|
|
|
|
cd frontend/admin
|
|
|
|
|
|
npm.cmd run lint
|
|
|
|
|
|
npm.cmd run build
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 真实浏览器
|
|
|
|
|
|
|
|
|
|
|
|
```powershell
|
|
|
|
|
|
cd frontend/admin
|
|
|
|
|
|
npm.cmd run e2e:full:win
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
## 4. 常见工程经验
|
|
|
|
|
|
|
|
|
|
|
|
- 如果结论依赖真实用户流程，就不要只跑单元测试。
|
|
|
|
|
|
- 如果终端出现乱码，不要把乱码文本继续复制进业务逻辑。
|
|
|
|
|
|
- 如果错误分级依赖字符串子串，后续大概率会回归；优先改成显式错误类型。
|
|
|
|
|
|
- 如果 service 依赖具体 repository 类型断言，后续替换实现或测试 mock 会变脆。
|
|
|
|
|
|
|
|
|
|
|
|
## 5. 文档维护规则
|
|
|
|
|
|
|
|
|
|
|
|
- 状态变更：更新 `docs/status/REAL_PROJECT_STATUS.md`
|
|
|
|
|
|
- 规则变更：更新 `docs/team/QUALITY_STANDARD.md`
|
|
|
|
|
|
- 发布门槛变更：更新 `docs/team/PRODUCTION_CHECKLIST.md`
|
|
|
|
|
|
- 阶段性经验：更新 `docs/team/PROJECT_EXPERIENCE_SUMMARY.md`
|
2026-04-11 10:41:08 +08:00
|
|
|
|
|
|
|
|
|
|
## 6. 2026-04-10 多轮 Review 实操指引
|
|
|
|
|
|
|
|
|
|
|
|
### 6.1 如何判断“是否闭环”
|
|
|
|
|
|
|
|
|
|
|
|
- 结论优先级：文档支持的主入口 > repo 内单步命令 > 局部 smoke、单个用例、`-short` 结果。
|
|
|
|
|
|
- 只要 `go test ./... -count=1` 仍被 `LL_001` 卡住，或 `npm.cmd run e2e:full:win` 仍未跑通，就不能把项目表述为“全量验证通过”。
|
|
|
|
|
|
- `go build ./cmd/server` 通过，只能证明 repo 内该命令通过；不能自动推出包装脚本里的 build 路径也稳定。
|
|
|
|
|
|
|
|
|
|
|
|
### 6.2 如何审查 stub 转 live 的高风险改动
|
|
|
|
|
|
|
|
|
|
|
|
- 先看权限边界：调用者是否真的具备读取或修改目标资源的资格。
|
|
|
|
|
|
- 再看治理边界：是否存在 `self-action`、`last-admin`、越权枚举、越权提升等问题。
|
|
|
|
|
|
- 再看一致性：多步写操作是否在事务内；失败时是否有显式回滚。
|
|
|
|
|
|
- 最后看文档与测试：是否补了负向测试、边界测试、回滚测试，以及状态文档与规范文档。
|
|
|
|
|
|
|
|
|
|
|
|
### 6.3 当前需要持续关注的热点
|
|
|
|
|
|
|
|
|
|
|
|
- `internal/service/scale_test.go`：`LL_001` 仍是全量 `go test ./... -count=1` 的门槛。
|
|
|
|
|
|
- `frontend/admin/scripts/run-playwright-auth-e2e.ps1`：需要优先保证文档支持的 `e2e:full:win` 入口自身稳定，而不是只验证子命令。
|
|
|
|
|
|
- `frontend/admin/src/components/common/ui-consistency.test.tsx`：原生弹窗噪声仍会污染测试结果，应继续清理。
|
|
|
|
|
|
- `internal/api/handler/user_handler.go` 与 `internal/service/user_service.go`：RBAC / 管理员治理逻辑需要持续按越权、事务、自删、最后管理员等维度审查。
|
