bsm-infra/full
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
full/docs/audit/module-base-feedback.md
yanweidong 63aeedc2fe docs: add per-module audit reports (18 modules) 
Add static security/quality audit reports for all 18 Go service modules under module/, plus a consolidated index (docs/audit/README.md) with per-module statistics, top risks, cross-module systemic defects and a phased TODO list (T1-T19). No production code is modified.
2026-09-14 22:16:27 +08:00

653 lines
72 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 审计报告：module/base/feedback
## 1. 模块概览
`base/feedback` 是用户反馈工单微服务，暴露一个 gRPC 服务 `feedback.Method`，共 6 个方法：`List / Get / Add / Modify / Delete / Remark`（`proto/feedback.proto:6-13`），数据落 PostgreSQL 三张表：`feedback_item`（主表）、`feedback_images`、`feedback_accessory`（`internal/models/feedback_item.go:33`、`feedback_images.go:24`、`feedback_accessory.go:25`）。
- 代码规模：非生成 Go 源码 12 个文件约 400 行（`cmd/main/main.go` 50 行、`internal/*` 7 个逻辑/模型/服务文件、`service/{dependencies,expose}.go`）；`pb/` 生成代码 4 个文件（含 97KB 的 `pb/const.pb.go`）；`test/` 仅 1 个 `.http` 样例 + 1 个整段注释的 `rpc.go`；**无任何 `*_test.go`**。
- 对外形式：gRPC + grpc-gateway。`cmd/main/main.go:21-46` 走 SDK `service.New/Start`（独立进程）；另一条路径是 `service.Expose`（`service/expose.go:18-26`），被 `pkgs/all/internal/service/feedback.go:9-20` 与 `pkgs/ecmall/internal/service/feedback.go:9-20` 注册进聚合进程。
- 网关路由：proto 无 `google.api.http` 注解，生成的 gateway 路径是裸路径 `POST /feedback.Method/{Method}`（`pb/feedback.pb.gw.go:206-324,472-477`）；聚合入口另有动态路径 `POST /rpc/feedback/Method/{Method}`（`wiki/api/04-feedback.md:9,25-30`、`pkgs/all/internal/server/server.go:61`）。
- 依赖外部组件：PostgreSQL（gorm）、Redis、内存缓存、Etcd（`internal/impl/impl.go:22-31`），其中 Redis/内存缓存**模块内无任何读取点**（见问题 23）。
- 配置：`etc/feedback.yaml`、`etc/feedback_{dev,test,prod}.yaml`，键名是 `Name/ListenOn/Dsn/Anonymous/Log/Prometheus/Telemetry`，与 SDK `conf.Base` 的 `Service/Port/BindIP/Databases/Cache` **完全不对应**（见问题 9）。
- 鉴权模型（前置结论）：聚合进程由宿主统一鉴权（`pkgs/all/internal/server/authorization.go:42-66` 的 unary 拦截器与 HTTP 中间件），`pkgs/all/etc/default_dev.yaml:24-43`、`pkgs/ecmall/etc/default_dev.yaml:24-43` 的匿名白名单**不含 `feedback.*`**，因此 6 个方法在聚合入口都要求 JWT；接口内部只有 `List/Add/Modify` 调用了 `service.ParseMetaCtx`（`list.go:19`、`add.go:21`、`modify.go:24`），且仅验签不校验归属。
## 2. 审计范围与方法
已读文件（全部非生成代码 + 配置 + proto + 文档）：`README.md`(542 行)、`cmd/main/main.go`、`cmd/cli/main.go`、`internal/config/config.go`、`internal/impl/impl.go`、`internal/logic/method/{add,list,get,modify,delete,ref,remark}.go`、`internal/models/{feedback_item,feedback_images,feedback_accessory}.go`、`internal/server/{new,method_server}.go`、`service/{dependencies,expose}.go`、`test/{add.http,rpc/rpc.go}`、`proto/{feedback,const}.proto`、`etc/*.yaml`、`go.mod`、`wiki/api/04-feedback.md`、`.builds/etc/feedback_prod.yaml`。
生成代码只做接口一致性检查：`pb.MethodServer` 6 个方法与 `internal/server/method_server.go:18-39` 的转发一致；`pb.FeedbackItem`/`FeedbackImage`/`FeedbackAccessory` 字段与 `internal/logic/method/ref.go:13-45` 的转换基本对齐（发现的缺字段见问题 6）；gateway 路由 `pattern_Method_*_0`（`pb/feedback.pb.gw.go:472-477`）与 README:175-180 一致。
为判定鉴权、GORM 语义与部署行为，另外读取了：`bsm-sdk/core/service/{meta.go,service.go,register.go}`、`conf/{new.go,types.go}`、`env/env.go`、`types/db.go`、`database/{new.go,sql/postgresql.go}`、`with/databases.go`、`crypto/token/jwt.go`、`pkgs/all/internal/{server/{server.go,authorization.go},service/feedback.go,impl/impl.go}`、`pkgs/all/etc/default_dev.yaml`、`pkgs/ecmall/internal/service/feedback.go`、`pkgs/ecmall/etc/default_dev.yaml`、`scripts/build-all-linux.sh`；以及 GORM v1.31.2 源码 `finisher_api.go`、`callbacks/update.go`、`callbacks/associations.go`、`callbacks/callbacks.go`、`statement.go`、`schema/schema.go`（用于确证 `Updates`/`Count`/关联保存的真实行为）。
静态检查（在本模块目录执行）：`gofmt -l .` → 无输出（全部已格式化）；`go vet ./...` → 退出码 0，无告警。两者作为基线门禁可保留（问题 26 的测试项另论）。
已核验为“无问题”的点（避免误判）：全部 SQL 条件均使用 `?` 占位符，`Order("created_at desc")` 为常量，**未发现注入点**（`list.go:39-71`、`get.go:29`、`delete.go:26`、`remark.go:32`）；业务代码中**未发现 `_ =` 忽略错误或未检查 err**（`add/list/get/modify/delete/remark` 每步都判 err）；`Add` 的图片/附件插入依赖 GORM 关联保存，Postgres 驱动默认开启事务（`database/sql/postgresql.go:32-41` 未设 `SkipDefaultTransaction`），**Add 本身是原子的**（Modify 不是，见问题 7）。
未覆盖/无法验证：未运行服务、未连接真实 PostgreSQL/Redis/Etcd，未 dump 线上表结构；`feedback_images.identity` / `feedback_accessory.identity` 的唯一索引是否真实存在取决于线上 DDL（模型声明了 `uniqueIndex`，但仓库内**找不到任何建表/迁移脚本**，见问题 16），凡依赖该前提的结论均已标注「推测」；未逐行阅读 `pb/feedback.pb.go`(1310 行) 与 `pb/const.pb.go`；SDK（`bsm-sdk/core`）与聚合服务（`pkgs/all`、`pkgs/ecmall`）仅按需读取片段，其自身问题只在与本模块调用点相关处引用。
## 3. 问题清单
### P0
#### 1. `Get`/`Delete`/`Remark` 既无鉴权也无归属校验，任意登录用户可读取、篡改、删除他人反馈
- **位置**：`module/base/feedback/internal/logic/method/get.go:19-35`、`delete.go:19-29`、`remark.go:19-35`；对照 `list.go:19`、`add.go:21`、`modify.go:24`
- **证据**：
```go
// get.go:19-29 —— 全程没有 ParseMetaCtx，也不比对 passport_identity
func Get(ctx context.Context, in *pb.GetRequest) (reply *pb.GetReply, err error) {
if in.GetIdentity() == "" { return nil, errcode.ErrInvalidArgument }
...
err = impl.DBService.Preload("Images").Where("identity = ?", in.GetIdentity()).First(record).Error
// delete.go:26
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Delete(new(models.FeedbackItem)).Error
// remark.go:32 —— 任意调用方直接指定 status，可把别人的工单标记为"已处理"
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Updates(record).Error
```
```go
// 对照：list.go:19 / add.go:21 / modify.go:24 —— 只有这三个方法解析了 JWT
auth, err := service.ParseMetaCtx(ctx, nil)
```
- **影响**：`identity` 是 36 位 UUID/ULID，但 `List` 会把它连同 email/phone 一起回给同机构用户，且日志/前端分享链接都可能泄露；拿到任意一个 identity 即可：①`Get` 读取他人反馈的 `email`/`phone`/`content`/`remark`（PII）；②`Remark` 改写状态与备注，把他人工单标记「已处理」或写入误导性备注；③`Delete` 软删他人工单。聚合入口的宿主拦截器只保证「已登录」（`pkgs/all/internal/server/authorization.go:43-51` 只验 JWT，`default_dev.yaml:24-43` 白名单不含 feedback），**不等于授权**。在 `cmd/main` 独立部署下更严重：`internal/server/new.go:23` 用 `grpc.NewServer()` 未装配任何拦截器，`Get/Delete/Remark` 连登录都不需要（`List/Add/Modify` 仍有 `ParseMetaCtx`）。
- **建议**：在 `Get/Modify/Delete/Remark` 统一先取 `auth`，并把查询条件写成 `Where("identity = ? AND (passport_identity = ? OR ?)", ...)`（或对管理端角色单独放行 `auth.Role`）；把「当前用户只能操作自己的工单」固化成 `models` 层唯一的辅助函数（如 `OwnedQuery(ctx)`），禁止 logic 直接拼 `identity = ?`；同时给独立入口装配与聚合一致的拦截器。
#### 2. `Modify` 用新 UUID 覆盖 `identity`，改写业务主键，导致记录失联与子表脱钩
- **位置**：`internal/logic/method/modify.go:35-52,64,72,89`；GORM 语义见 `callbacks/update.go:274-304`
- **证据**：
```go
// modify.go:35-38 —— 更新用的结构体里塞了一个全新 UUID
record := &models.FeedbackItem{
Std_IICUDS: types.Std_IICUDS{
Identity: utils.UUID(),
},
...
// modify.go:89 —— 结构化 Updates 会把所有非零、非主键字段写进 SET
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Updates(record).Error
```
```go
// gorm v1.31.2 callbacks/update.go:276-295 —— 只有主键被排除在 SET 之外
for _, dbName := range stmt.Schema.DBNames {
if field := updatingSchema.LookUpField(dbName); field != nil {
if !field.PrimaryKey || ... {
...
if (ok || !isZero) && field.Updatable {
set = append(set, clause.Assignment{Column: clause.Column{Name: field.DBName}, Value: value})
```
- **影响**：`FeedbackItem` 的主键是 `id`（`bsm-sdk/core/types/db.go:29`），`identity` 只是 `uniqueIndex` 列，因此被判为可更新字段；GORM 实际生成 `UPDATE feedback_item SET identity='<新UUID>', passport_identity=..., ... WHERE identity='<旧identity>'`。本条属于**必然发生的语义性数据损坏**：一次成功的 `Modify` 之后，原 identity 再也查不到该工单（`Get`/`Delete`/`Remark`/`List` 全部按 identity 查询），而 `modify.go:64,72` 写入的 `item_identity` 仍是调用方传入的旧 identity（关联保存路径又会用 `record` 的新 identity 覆盖它，见问题 7），子表与主表就此脱钩，形成无法通过 API 追溯的孤儿数据。仓库中 `.builds/_tmp_gorm_probe/main.go:34-41` 正是为验证「struct Updates 会写入哪些列」而留的探针，说明该行为已被怀疑过但未修复。
- **建议**：更新用结构体不要带 `Identity`（或删除该字段赋值），并把 `Updates` 改成 map/`Select` 显式列出可改字段（`title/content/category/status/remark/email/phone`）；`identity` 应加 `gorm:"->"`（只读）或在业务上禁止写入；补一条单测断言 `Modify` 前后 `identity` 不变。
#### 3. 生产数据库账号口令与内网拓扑硬编码进仓库，并随构建产物一同发布
- **位置**：`module/base/feedback/etc/feedback_prod.yaml:4`、`.builds/etc/feedback_prod.yaml:4`、`scripts/build-all-linux.sh:95-102`
- **证据**：
```yaml
# etc/feedback_prod.yaml:4（.builds/etc/feedback_prod.yaml:4 内容完全相同）
Dsn: postgres://prod:MakeW2023~PROD@192.168.0.224:5432/scf?sslmode=disable&TimeZone=Asia/Shanghai
# etc/feedback_prod.yaml:7,11,40
Cache: redis://null:CHANGE_ME@192.168.0.43:6379/
- 192.168.0.83:2379
Endpoint: http://139.159.232.50:14268/api/traces
```
```bash
# scripts/build-all-linux.sh:98-100 —— 构建时把该配置复制进产物目录
config_file="${module_dir}/etc/${config_name}"
[[ -f "${config_file}" ]] || continue
cp -- "${config_file}" "${CONFIG_ROOT}/${config_name}"
```
- **影响**：一个看起来是真实凭据的 `prod:MakeW2023~PROD@192.168.0.224/scf` 明文提交在版本库中，同时暴露生产 DB 主机、Redis 主机（.43）、Etcd 主机（.83）、Jaeger 采集端（139.159.232.50，公网 IP）与库名 `scf`；`sslmode=disable` 意味着凭据与业务数据在链路上明文传输。任何能读到仓库或构建产物（`.builds/etc/`，`scripts/build-all-linux.sh:100` 自动复制）的人即可直连生产库。此外 `Cache: redis://null:CHANGE_ME@...` 的占位口令会被 `conf.NotNil` 当作合法值放行。
- **建议**：立即轮换 `prod` 账号口令并清理 git 历史（`git filter-repo`），把 DSN/Redis/Etcd 全部改为环境变量或密钥管理注入；生产 DSN 使用 `sslmode=require` 与最小权限账号（仅 `feedback_*` 表 DML）；启动时增加「拒绝 `CHANGE_ME`、拒绝 `sslmode=disable`」的 fail-fast 校验（`internal/config/config.go` 增加校验点）。
### P1
#### 4. `List` 的分页总数在第 2 页及以后恒为 0（`Find` 之后复用同一 Statement 调 `Count`）
- **位置**：`internal/logic/method/list.go:71`
- **证据**：
```go
// list.go:71 —— Limit/Offset/Order 与 Find、Count 在同一次链式调用上
if err := sess.Limit(int(in.GetSize())).Offset(int(offset)).Order("created_at desc").Find(&list).Count(&count).Error; err != nil {
```
```go
// gorm v1.31.2 finisher_api.go:497-511 —— Count 只删除 ORDER BY，LIMIT/OFFSET 会被带进 count 语句
if orderByClause, ok := db.Statement.Clauses["ORDER BY"]; ok {
if _, ok := db.Statement.Clauses["GROUP BY"]; !ok {
delete(tx.Statement.Clauses, "ORDER BY")
...
if _, ok := db.Statement.Clauses["GROUP BY"]; ok || tx.RowsAffected != 1 {
*count = tx.RowsAffected
```
- **影响**：`Count` 生成的 SQL 是 `SELECT count(*) ... WHERE ... LIMIT 10 OFFSET 10`；聚合行只有 1 行，`OFFSET 10` 使其被跳过，`RowsAffected=0 != 1`，于是 `count` 被写成 0。**第 1 页总数正确、第 2 页起 `count=0`**，前端分页器无法翻页（或显示「共 0 条」），且 `ListReply.count` 是唯一的条目总数来源（`list.go:76-79`）。深分页本身也随 offset 增大而变慢（见问题 11）。
- **建议**：拆成两条独立语句：先 `sess.Count(&count)`（不带 Limit/Offset），再 `sess.Limit(size).Offset(offset).Order("created_at desc").Find(&list)`；或改用 `Session(&gorm.Session{})` 派生新会话。补单测断言 `page=2` 时 `count` 等于真实总数。
#### 5. `List` 的 `user_name` 过滤引用了不存在的列 `username`，带该条件即 SQL 报错
- **位置**：`internal/logic/method/list.go:48-51`；列名定义 `internal/models/feedback_item.go:15`
- **证据**：
```go
// list.go:50
sess = sess.Where("username = ?", username)
// feedback_item.go:15 —— 模型列名是 user_name（README:444 的建表语句同为 user_name）
UserName string `gorm:"column:user_name;type:varchar(20);default:'';" json:"user_name"` // 用户名
```
- **影响**：`Where("username = ?")` 是原样 SQL 片段，PostgreSQL 会报 `column "username" does not exist`，请求以 500/`Unknown` 返回；即只要前端在列表页按用户名搜索就必然失败（除非线上表另有一个遗留 `username` 列，属**推测**，模型与 README 的 DDL 均不支持该前提）。同时 `email`/`phone`/`store_identity`/`user_identity` 四个筛选字段在 proto（`proto/feedback.proto:23-25`）与 wiki（`wiki/api/04-feedback.md:42-49`）中公开，但逻辑中完全没有实现，调用方会静默拿到未被过滤的全量结果——这比报错更危险。
- **建议**：改为 `Where("user_name = ?", username)`；把未实现的筛选字段要么实现（email/phone 精确匹配）要么从 proto 与文档中删除；对 `/rpc` 动态接口增加「请求字段全量实现」的契约测试。
#### 6. `Add`/`Modify` 静默丢弃 `category`/`agency`/`store_identity`，响应又从不回传这些字段
- **位置**：`internal/logic/method/add.go:27-43`、`modify.go:35-52`、`ref.go:13-26`；proto 字段 `proto/feedback.proto:78,83,49-50`
- **证据**：
```go
// add.go:35-42 —— AddRequest 有 category(10)/agency(15)/store_identity(14)，构造时全部未赋值
UserName: in.GetUserName(),
Status: in.GetStatus(),
Email: in.GetEmail(),
Phone: in.GetPhone(),
Title: in.GetTitle(),
Content: in.GetContent(),
// modify.go:43-51 同样没有 Agency / StoreIdentity
// ref.go:14-26 —— 出参也不含 UserIdentity / Agency / StoreIdentity
Identity: item.Identity, UserName: item.UserName, Email: item.Email, Phone: item.Phone,
```
- **影响**：`Add` 是全模块唯一的工单创建入口，但它写入的记录 `category`/`agency` 恒为 `''`，`store_identity` 在模型里根本没有对应列（`feedback_item.go:14-24` 无该字段）→ 提交方传的分类/机构/店铺信息**永久丢失**；连带 `List` 的 `category`（`list.go:60-63`）与 `agency`（`list.go:38-39`）过滤对新建数据恒不匹配，`wiki/api/04-feedback.md:45` 文档化的 `store_identity` 字段在整条链路上不存在。同理 `Get`/`List` 回包的 `user_identity`/`agency`/`store_identity`（proto 字段 2/16/15）永远是空串，管理端无法判断工单归谁、属于哪个机构。
- **建议**：`Add`/`Modify` 补齐 `Category`/`Agency` 赋值并在模型中新增 `store_identity`（或从 proto 删除）；`convert()` 补 `UserIdentity`/`Agency`/`StoreIdentity`；把 proto 字段与模型列的对应关系写成表驱动测试，避免再次静默丢字段。
#### 7. `Modify` 的关联写入重复、附件缺失 identity、且整段无事务
- **位置**：`internal/logic/method/modify.go:70-76,79-86,89-106`；GORM 关联回调 `callbacks/callbacks.go:72`、`callbacks/associations.go:189-259`、`statement.go:771`
- **证据**：
```go
// modify.go:70-76 —— 附件循环没有生成 Identity（Add 中同位置有 utils.UUID()）
for _, v := range in.GetAccessories() {
record.Accessories = append(record.Accessories, models.FeedbackAccessory{
ItemIdentity: in.GetIdentity(), Title: v.Title, FilePath: v.FilePath,
})
}
// modify.go:79-106 —— 先软删子表、再更新主表、最后显式 Create；三步之间无事务
err = impl.DBService.Where("item_identity = ?", in.GetIdentity()).Delete(&models.FeedbackImage{}).Error
...
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Updates(record).Error // 该语句自身还会保存关联
...
if len(record.Images) > 0 { err = impl.DBService.Create(&record.Images).Error }
```
```go
// gorm v1.31.2 callbacks/callbacks.go:72 —— UPDATE 回调注册了 after-associations
updateCallback.Register("gorm:save_after_associations", SaveAfterAssociations(false))
// statement.go:771 —— 未显式 Select 时 restricted=false，HasMany 分支不会被跳过
return results, !notRestricted && len(stmt.Selects) > 0
```
```go
// bsm-sdk/core/types/db.go:30 —— identity 带 uniqueIndex，软删行仍占用该唯一值
Identity string `gorm:"column:identity;type:varchar(36);uniqueIndex;" json:"identity"`
```
- **影响**：三处相互叠加的缺陷：①**附件 identity 为空串**，多个附件会写入同一空值（Add 中每个附件都有 `utils.UUID()`，此处遗漏，`add.go:57-65` 可对照）；②`Updates(record)` 会触发 GORM 的 after-associations 回调，把 `record.Images`/`record.Accessories` 再插一遍（关联保存时还会用 `record` 的新 identity 覆盖 `item_identity`），随后 `modify.go:96,102` 又显式 `Create` 同一批 identity 的行——两条写入路径必然都发生，结果是重复行，或（若 `identity` 唯一索引存在）第二次插入报重复键（**哪种结果取决于线上 DDL，属推测；但"同一批子行被写两次"由上述回调链确定**）；③**无事务**：软删子表成功后主表或重建失败，就留下「主表 identity 已被改写、图片已删、附件残缺」的中间态，且由于问题 2，事后连原记录都找不到，无法补偿。此外硬删除前的软删让旧行继续占用 identity，与 ①空 identity 共同构成唯一键冲突的高发路径。
- **建议**：用 `impl.DBService.Transaction(func(tx *gorm.DB) error {...})` 包住「删子表 → 更新主表 → 重建子表」，所有语句改用 `tx`；附件补齐 `Identity: utils.UUID()`；更新主表时 `Omit(clause.Associations)` 或显式 `Select` 字段，避免关联被隐式再写；重建前先判断 `RowsAffected`。补测试：2 个附件的 Modify、缺省 identity 的图片、故意在第 3 步注入错误后断言回滚。
#### 8. `Get`/`List` 未预加载 `Accessories`，附件在响应中永远为空
- **位置**：`internal/logic/method/get.go:29`、`list.go:35`、`ref.go:38-45`
- **证据**：
```go
// get.go:29 / list.go:35 —— 只 Preload 了 Images
err = impl.DBService.Preload("Images").Where("identity = ?", in.GetIdentity()).First(record).Error
sess := impl.DBService.Preload("Images")
// ref.go:38-45 —— 却把 Accessories 一并转换后返回
for _, accessory := range item.Accessories {
reply.Accessories = append(reply.Accessories, &pb.FeedbackAccessory{...})
```
- **影响**：`FeedbackItem` 声明了 `Accessories` 关联（`models/feedback_item.go:24`），转换函数也依赖它，但两条查询路径都没有 `Preload("Accessories")`，GORM 不会自动填充 → `Get`/`List` 返回的 `accessories` 永远是空数组；用户提交的附件（`add.go:57-66` 确实写库）在详情与列表里不可见，只有直接查库才能看到。
- **建议**：两处改为 `Preload("Images").Preload("Accessories")`；补一条集成测试，断言 `Add` 带附件后 `Get` 能取回同名附件。
#### 9. 独立部署入口（`cmd/main`）实际不可用：配置键与 SDK 不匹配导致启动即 fatal，且 `Mux` 恒为 nil
- **位置**：`module/base/feedback/etc/feedback_{dev,test,prod}.yaml:1-4`、`internal/config/config.go:29-44`、`internal/server/new.go:16,20-30`、`cmd/main/main.go:28,37`
- **证据**：
```yaml
# etc/feedback_prod.yaml:1-4 —— 用的是旧键名；同目录 dev/test 文件结构相同
Name: {ServiceKey}
ListenOn: 0.0.0.0:12210
Dsn: postgres://prod:...@192.168.0.224:5432/scf?...
```
```go
// bsm-sdk/core/conf/types.go:7-21 —— Base 只有 Service/Port/Cache/SecretKey/BindIP/Addr/Log，没有 Name/ListenOn/Dsn
type Base struct { Service string `yaml:"Service"`; Port string `yaml:"Port"`; ... }
type DBConf struct { Driver string `yaml:"Driver"`; Source []string `yaml:"Source"` }
// bsm-sdk/core/conf/new.go:35-36,58-60 —— 按 feedback_{mode}.yaml 读取，且强制要求出现 "Service:"
cfp := fmt.Sprintf("%s_%s.yaml", strings.ToLower(srvKey), env.Runtime.Mode)
if !strings.Contains(yamlString, "Service:") { log.Fatalln("ERROR: Service Not Nil", cfp) }
// bsm-sdk/core/with/databases.go:13-15 —— Databases 为 nil 时直接 panic
if cfg == nil || len(cfg.Source) == 0 { panic("No Database Source Found !") }
```
```go
// internal/server/new.go:16,26-30 —— Mux 字段声明了但从未赋值
Mux *gwRuntime.ServeMux
srv := &Server{ Ctx: context.Background(), Grpc: grpcServ, grpcConns: map[string]*grpc.ClientConn{} }
// cmd/main/main.go:37 —— 于是把 nil 交给 SDK 当网关 handler
GatewayMux: s.Mux,
```
- **影响**：三份模块配置里的 `Name/ListenOn/Dsn/Anonymous(映射)/Log.ServiceName/Log.Mode/Prometheus/Telemetry` 都不是 `SrvConfig` 的字段（`internal/config/config.go:17-25`），`conf.New` 在读到 `feedback_prod.yaml` 后会因找不到 `"Service:"` 直接 `log.Fatalln`；即使补上 `Service:`，`Databases` 也仍是 nil，`with.Databases` 会 panic，且 `Spec.Port` 恒为空 → 走 `conf.CheckPort` 的随机端口分支（`conf/new.go:90-96`），与配置里写的 12210 完全脱节。同时网关路由只可能在 `service.Expose`（`service/expose.go:23`）里注册，`cmd/main` 从不调用它，`s.Mux` 永远是 nil，SDK `service.Gateway` 会把 nil handler 交给 `http.ListenAndServe`（`bsm-sdk/core/service/service.go:126`）→ 落到 `DefaultServeMux`，README:175-180 与 `wiki/api/04-feedback.md:11` 文档化的 HTTP 端点全部 404。其他模块（例：`module/base/ads/etc/ads_dev.yaml:1-7` 用 `Service:/Port:/Databases:`）证明这是本模块配置未随 SDK 升级的落后，而非 SDK 行为。`scripts/build-all-linux.sh:52-71,97-100` 仍在为每个模块构建独立二进制并发布这份配置，因此该路径是**随时会被启用的雷**。
- **建议**：把 `etc/feedback_{dev,test,prod}.yaml` 重写为 `Service/Port/BindIP/Databases.Driver+Source/Cache/MicroService` 结构（对照 ads 或钱包模块），并删除 `Dsn/ListenOn/Name` 旧键；在 `internal/server.New()` 里 `Mux: gwRuntime.NewServeMux()` 并调用 `pb.RegisterMethodHandlerServer(srv.Ctx, srv.Mux, NewMethodServer())`，让 `cmd/main` 与 `service.Expose` 走同一条注册路径；补一条启动自检（配置解析 + `Databases != nil` + 网关路由探活）。
#### 10. `List` 的 `agency` 分支绕开用户隔离，可越权读取他人反馈
- **位置**：`internal/logic/method/list.go:37-45`
- **证据**：
```go
// list.go:37-45 —— 传了 agency 就完全不再按 passport_identity 收窄
if in.GetAgency() != "" {
sess = sess.Where("agency = ?", in.GetAgency())
} else {
userIdentity := auth.Identity
if userIdentity != "" {
sess = sess.Where("passport_identity = ?", userIdentity)
}
}
```
- **影响**：`agency` 是调用方可控的普通请求字段（`proto/feedback.proto:26`），一旦传入就跳过 `passport_identity` 过滤，返回该机构下**所有用户**的工单（含 email/phone/content）。同样的 `else` 分支还有一个次生缺陷：当 `auth.Identity` 为空串时不加任何用户条件，等价于全表分页读取——`service.ParseMetaCtx` 只校验签名不校验 identity 非空（`bsm-sdk/core/service/meta.go:19-47`），服务间令牌或经特殊签发的令牌会命中该分支。需注意：本模块的 `Add`/`Modify` 都不写 `agency`（问题 6），因此「按 agency 越权」的**实际可利用性取决于库中是否已存在非空 agency 的历史数据**（属推测）；但 `auth.Identity == ""` 走全表这条分支不依赖任何历史数据。
- **建议**：把机构维度改成「先按身份收窄、再叠加机构过滤」：`sess.Where("passport_identity = ?", auth.Identity)`，管理端查询另开角色判定（`ParseMetaCtx(ctx, &service.ParseOptions{RoleValue: "admin"})`）；`auth.Identity == ""` 时立即返回 `ErrPermissionDenied` 而不是放行全表；`agency` 应从客户端入参改为由服务端身份/机构配置推导。
#### 11. 关键索引缺失 + `OFFSET` 深分页：每次列表/详情都是一次子表全表扫描
- **位置**：`internal/models/feedback_images.go:13`、`feedback_accessory.go:13`、`feedback_item.go:22`、`list.go:35,71`
- **证据**：
```go
// feedback_images.go:13 / feedback_accessory.go:13 —— item_identity 无 index 标签（对比 Std_Passport 的 passport_identity 有 Index）
ItemIdentity string `gorm:"column:item_identity;type:varchar(36);default:'';" json:"item_identity"`
// feedback_item.go:22 —— agency 无索引，却作为 List 的过滤列
Agency string `gorm:"column:agency;type:varchar(255);default:'';" json:"agency"`
// list.go:35,71 —— Preload 触发 `WHERE item_identity IN (...)`，排序列为 created_at（无索引）
sess := impl.DBService.Preload("Images")
... .Order("created_at desc").Find(&list) ...
```
- **影响**：`Preload("Images")` 生成的 `SELECT * FROM feedback_images WHERE item_identity IN (...) AND deleted_at IS NULL` 没有可用索引（模型未声明，且见问题 16 迁移不会执行），随子表增长退化为顺序扫描；`feedback_accessory` 同理（虽当前未被 Preload，见问题 8）。`ORDER BY created_at DESC` 也没有索引，`OFFSET` 越大越慢（问题 4 的第 N 页查询要扫描并丢弃 `(page-1)*size` 行）。叠加问题 1/10 的越权读，构成可被外部放大的资源消耗路径。README:320-325 声称「关键字段建立复合索引」「使用预加载减少 N+1 查询」，其中索引部分在模型里没有任何落点。
- **建议**：为 `feedback_images(item_identity)`、`feedback_accessory(item_identity)`、`feedback_item(passport_identity, created_at)`、`feedback_item(agency)` 建索引并纳入可执行迁移；把 `OFFSET` 分页改为基于 `(created_at, id)` 的 keyset 分页；列表查询用 `WithContext` 加超时。
### P2
#### 12. 数据库调用完全没有 `context` 传递，也没有超时/重试
- **位置**：`internal/logic/method/{list,get,add,modify,delete,remark}.go`（全部数据访问）
- **证据**：
```go
// get.go:29 —— ctx 只用于 ParseMetaCtx（且 get 连这步都没有），从未进入 DB 调用
err = impl.DBService.Preload("Images").Where("identity = ?", in.GetIdentity()).First(record).Error
// 全模块 grep 结果：无任何 WithContext 调用
```
- **影响**：`ctx` 参数在 `Get/Delete/Remark` 中甚至完全未使用（编译期不会报错），客户端断开或上游超时后 SQL 继续在服务端执行，慢查询会占满 `SqlOptionMaxOpenConns=64`（`bsm-sdk/core/vars/sql.go:8`）的连接池并拖垮整个聚合进程；gRPC 层也未设置服务端超时/`grpc.KeepaliveParams`（`internal/server/new.go:23` 用默认 `grpc.NewServer()`）。没有重试/熔断，也没有任何降级。
- **建议**：统一改为 `impl.DBService.WithContext(ctx)`，在 gRPC 拦截器或 logic 入口设置 `context.WithTimeout`（如 3s）；为读接口加只读重试（幂等）；把连接池与超时参数显式传入 `with.Databases(cfg, &types.SqlOptions{...})`。
#### 13. 业务 panic 无恢复：独立入口无拦截器，聚合入口的 gRPC 路径也没有 recovery
- **位置**：`internal/server/new.go:20-30`、`pkgs/all/internal/server/server.go:32`、`service/dependencies.go:19-32`
- **证据**：
```go
// internal/server/new.go:23 —— 没有任何 unary/stream 拦截器（鉴权/recover/日志/限流全缺）
grpcServ = grpc.NewServer()
// pkgs/all/internal/server/server.go:32 —— 聚合只装了鉴权拦截器，无 recovery
grpcServer := grpc.NewServer(grpc.UnaryInterceptor(auth.unaryInterceptor))
```
- **影响**：`impl.DBService` 等全局依赖一旦为 nil（例如调用方使用 `service.Expose` 却未传 `Dependencies.DB`，见问题 18），`impl.DBService.Preload(...)` 会以 nil 接收者 panic；gRPC 服务端未装 `recovery` 拦截器时该 panic 会终止**整个进程**（聚合进程承载 14+ 模块）。聚合 HTTP 侧有 `gin.Recovery()`（`server.go:35`）与 `http.Server` 兜底，但 `grpc-gateway` 的 `RegisterMethodHandlerServer` 路径（`service/expose.go:23`）是进程内直调，最终仍落到未保护的 gRPC 方法实现上。
- **建议**：为 gRPC 增加 recovery 拦截器（`grpc_recovery` 或自写，log + 返回 `codes.Internal`），并在 `Expose`/`NewImpl` 里对 DB 做非空校验（问题 18）；关键逻辑入口加 `defer recover` 兜底并上报。
#### 14. 无结构化日志、无健康检查、无指标；数据库原始错误直接回给调用方
- **位置**：全部 logic（无 logger 调用）、`internal/server/new.go:33-37`、`internal/config/config.go:23`
- **证据**：
```go
// modify.go:89-92 —— 原始 GORM/PG 错误未经包装直接上抛（gRPC 层会映射为 Unknown + SQL 文本）
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Updates(record).Error
if err != nil { return nil, err }
// internal/server/new.go:33-36 —— 只注册业务服务与 reflection，没有 health 服务
pb.RegisterMethodServer(srv.Grpc, NewMethodServer())
if standalone { reflection.Register(srv.Grpc) }
```
- **影响**：模块内没有任何日志语句，问题定位只能依赖宿主；`reflection` 在生产独立部署下无条件开启（`new.go:35-37`），可被匿名枚举服务与消息结构。唯一违反 NOT NULL 或重复键时会返回 `duplicate key value violates unique constraint "idx_feedback_images_identity"` 之类的原始 SQL 文本，向调用方泄露表名/索引名；配置里的 `APM`（`config.go:23`）与 `Prometheus/Telemetry`（prod yaml:32-42）从未被读取（问题 23），因此没有任何指标与链路数据。README:330-335 声称有 `/health` 与 `/metrics` 端点，仓库内无实现。
- **建议**：接入 SDK logger（`printer`/`logger`），错误统一包装为 `errcode`（保留原始 err 于日志而非响应体）；注册 `grpc_health_v1` 健康服务；reflection 改为配置开关且生产默认关闭；APM/Prometheus 要么接上要么从配置删除。
#### 15. 生产环境默认开启 GORM `Debug`，SQL 与 email/phone/正文明文写入日志（PII）
- **位置**：`internal/impl/impl.go:28`、`bsm-sdk/core/database/sql/postgresql.go:11-24,46-48`
- **证据**：
```go
// internal/impl/impl.go:28 —— opts 传 nil
DBService = with.Databases(config.Spec.Databases, nil)
// bsm-sdk/core/database/sql/postgresql.go:13-20,46-48 —— 默认 Debug:true，随即 gormDb.Debug()
options = &types.SqlOptions{ ..., IsAutoMigrate: false, LogStdout: false, Debug: true }
if options.Debug { gormDb = gormDb.Debug() }
```
- **影响**：`Debug()` 会把每条 SQL 连参数一起打印（`Explain` 后的完整语句），而本模块的 SQL 参数包含 `email`、`phone`、反馈正文、附件 URL 与用户 identity；日志模式为文件且无脱敏钩子 → PII 落盘并可能被集中采集。聚合进程同样传 nil（`pkgs/all/internal/impl/impl.go:38`），影响面不止本模块。README:407-415 还指导用户 `grep ERROR logs/feedback.log`，但 `Log` 配置键（yaml 用 `Mode/Path/Stat`）与 SDK `LogConf`（`Name/Level/Dir/Endpoint/Console/File/Remote`）不匹配 → 日志级别/路径配置实际全部失效。
- **建议**：生产显式传 `&types.SqlOptions{Debug:false, IsAutoMigrate:false}`（或按 `BSM_RuntimeMode` 切换）；若必须留 SQL 日志，接入 `logger.ParamsFilter` 对 email/phone 做掩码；修正 `Log` 配置键。
#### 16. 迁移与建表不可执行：`MigrateTables` 登记形同虚设，仓库内无任何 DDL，README 的迁移命令不存在
- **位置**：`internal/models/{feedback_item.go:27-30,feedback_images.go:17-20,feedback_accessory.go:18-21}`、`internal/impl/impl.go:28`、`README.md:266-270`
- **证据**：
```go
// feedback_item.go:27-30 —— 三个模型都把自己登记进全局迁移表
func init() { database.MigrateTables = append(database.MigrateTables, &FeedbackItem{}) }
// bsm-sdk/core/database/new.go:43-48 —— 但只有 IsAutoMigrate 为真才会执行
if len(MigrateTables) > 0 && options.IsAutoMigrate { err = db.AutoMigrate(MigrateTables...) }
// bsm-sdk/core/database/sql/postgresql.go:17 —— 默认 false，且 conf.DBConf 只有 Driver/Source，无法从 YAML 打开
IsAutoMigrate: false,
```
- **影响**：本模块既没有 `migrations/` 或 `.sql` 文件（全仓库 grep `feedback_item` 无任何建表语句），也没有可执行迁移入口，`init()` 登记的唯一效果是让 `database.MigrateTables` 全局变量增长；README:268-269 教用户执行 `go run cmd/main/main.go migrate`，但 `cmd/main/main.go:21-49` 只有 `Run()/main()`，没有子命令解析，该命令必然是空跑。聚合模式下更甚：`pkgs/all`/`pkgs/ecmall` 只调 `applyDependencies` 注入共享 DB，从不调用本模块的 `impl.NewImpl()`，且聚合库是 `bsm_dev`（`pkgs/ecmall/etc/default_dev.yaml:14`）而本模块独立配置指向 `milu`（`etc/feedback_dev.yaml:4`）→ 上线前若无人手工建表，所有接口都会以 `relation "feedback_item" does not exist` 失败；表结构（尤其是 `deleted_at`、`identity` 唯一索引）与模型是否一致也无从校验。
- **建议**：提交版本化 DDL（含三张表、`deleted_at`、上述索引），提供独立的 `cmd/migrate` 或启动可配的 `IsAutoMigrate` 开关，并把「聚合库必须含 feedback_* 表」写入部署检查清单；删除 README 中不存在的命令。
#### 17. 优雅退出不可达：`Start()` 内 `select {}` 让 `defer srv.Stop()` 永不执行，且无信号处理
- **位置**：`cmd/main/main.go:41-45`、`bsm-sdk/core/service/service.go:98-115,141-144`
- **证据**：
```go
// cmd/main/main.go:41-45 —— 期望 defer 在退出时优雅停止
defer srv.Stop()
srv.Start()
// bsm-sdk/core/service/service.go:113-115 —— Start 内部永久阻塞，defer 永远不触发
// 阻塞主线程
select {}
```
- **影响**：独立部署的进程只能被强杀（`SIGKILL`）或依赖运行时默认的 `SIGTERM` 立即终止行为，在途 gRPC 请求被截断，`GrpcSrv.GracefulStop()`（`service.go:142-144`）形同虚设；模块内也没有 `signal.Notify` + `s.http.Shutdown` 的关停编排（对比聚合侧 `pkgs/all/internal/server/server.go:92-110` 有 `Stop(ctx)`）。同时 DB/Redis/Etcd 连接没有关闭点。
- **建议**：模块自行实现信号处理（`signal.NotifyContext`）并在收到信号后按序 `GracefulStop` → 关闭 DB/Redis/Etcd，设置关停超时；或在 SDK `Start()` 里改为阻塞在可取消的 channel 上，让 `defer Stop()` 生效。
#### 18. `Expose`/依赖注入不校验 nil，缺依赖时是运行期 panic 而不是启动失败
- **位置**：`service/dependencies.go:19-32`、`service/expose.go:18-26`
- **证据**：
```go
// dependencies.go:19-31 —— 只在非 nil 时覆盖，没有任何「必填」校验
func applyDependencies(deps Dependencies) {
if deps.DB != nil { impl.DBService = deps.DB }
...
// expose.go:20-23 —— GRPC/Gateway 直接透传，nil 会在 Handle/注册阶段炸
server.New(options.GRPC)
if err := pb.RegisterMethodHandlerServer(ctx, options.Gateway, server.NewMethodServer()); err != nil {
```
- **影响**：`Expose` 是聚合侧唯一入口，若调用方忘记传 `DB`（或 `GRPC`/`Gateway`），服务照常「注册成功」，直到第一个请求才 panic（`impl.DBService` 为 nil）；`server.New` 的返回值被丢弃（`expose.go:20`），`Mux` 恒为 nil 的事实也无从暴露（问题 9）。与聚合侧 `newAuthorization` 的 fail-fast 风格（`pkgs/all/internal/server/authorization.go:25-40` 缺 key 直接返回错误）不一致。
- **建议**：`Expose` 入口做 `if options.DB == nil || options.GRPC == nil || options.Gateway == nil { return fmt.Errorf(...) }`，并把 `server.New` 的 `*Server` 用于初始化 `Mux`/校验；`applyDependencies` 返回 error 而不是静默跳过。
#### 19. 写接口忽略 `RowsAffected`：对不存在的记录返回「成功」，且 `Updates(struct)` 无法清空字段
- **位置**：`internal/logic/method/delete.go:26-34`、`remark.go:32-40`、`modify.go:89-111`
- **证据**：
```go
// delete.go:26-34 —— 不检查 RowsAffected 即返回 OK
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Delete(new(models.FeedbackItem)).Error
if err != nil { return nil, err }
return &pb.StatusReply{Message: vars.OK, Timeseq: time.Now().UnixMilli()}, nil
// remark.go:26-32 —— Updates(struct) 忽略零值，也无法把 remark 清空为 ""
record := &models.FeedbackItem{
Remark: in.GetRemark(), // 备注内容
Status: in.GetStatus(), // 状态
}
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Updates(record).Error
```
- **影响**：传入任意不存在（或无权访问，见问题 1）的 identity，`Delete`/`Remark`/`Modify` 都返回 `code=0/OK`，调用方无法区分「删除成功」与「什么也没发生」，审计与告警全部失真；`Updates(struct)` 跳过零值字段意味着「清空备注」「把状态设回 0」在 API 层不可表达（前端会显示已保存但值未变）。
- **建议**：统一检查 `result.RowsAffected == 0 → ErrRecordNotFound`；需要可空语义的字段改用 `map[string]any` 或 `Select` 显式指定列；把 `Status`/`Remark` 的可空写法与 proto 的 optional 语义对齐。
#### 20. 模型 `status` 同列双重定义且语义冲突，状态流转无任何校验
- **位置**：`internal/models/feedback_item.go:12,18`、`bsm-sdk/core/types/db.go:28-35`、`add.go:36`、`remark.go:26-32`
- **证据**：
```go
// feedback_item.go:12,18 —— 嵌入式 Std_IICUDS 已带 Status int8（-1禁止/1正常），外层又定义 int32（1未处理/2已处理）
type FeedbackItem struct {
types.Std_IICUDS
Status int32 `gorm:"column:status;default:1;" json:"status"` // 状态,1未处理,2已处理
// bsm-sdk/core/types/db.go:34
Status int8 `gorm:"column:status;default:0;index;" json:"status"` // 状态：默认为0，-1禁止，1为正常
```
- **影响**：GORM 按「同名列取绑定名更短者」的规则解析（`schema/schema.go:230-258`），外层 `int32 Status` 胜出，内层 `int8 Status`（连同它的 `index` 与 `-1/1` 语义）被覆盖——同一张表同一个 `status` 列被两套互斥的语义定义，任何写入方（`Add` 直取 `in.GetStatus()`、`Remark` 直取 `in.GetStatus()`）都没有状态机约束：调用方可以创建时就写 `status=2`（伪造「已处理」），也可以把已完成的工单改回 `1`，管理端无法据此做 SLA 统计。内层字段的 `index` 是否仍被 DDL 生成取决于阴影解析（属**推测**），但语义冲突确定存在。
- **建议**：把业务状态从 `Std_IICUDS.Status` 中剥离为独立命名（如 `HandleStatus`，列 `handle_status`）或显式 `Omit` 内层字段；定义 `StatusPending=1/StatusHandled=2` 常量并集中校验合法迁移（1→2、2→1 需权限），禁止 `Add` 直接设置处理状态。
#### 21. 提交路径无限流、无幂等、无长度校验
- **位置**：`internal/logic/method/add.go:19-74`、`internal/models/feedback_item.go:15-21`
- **证据**：
```go
// add.go:69-74 —— 无任何去重/限流/长度检查，直接落库并返回新 identity
err = impl.DBService.Create(record).Error
if err != nil { return nil, err }
return &pb.AddReply{Identity: record.Identity}, nil
// feedback_item.go:15,20 —— 列宽固定，超长输入由数据库报错
UserName string `gorm:"column:user_name;type:varchar(20);default:'';" json:"user_name"` // 用户名
Content string `gorm:"column:content;type:varchar(500);" json:"content"` // 内容
```
- **影响**：`Add` 是唯一的用户侧写入口，任何已登录用户都能以脚本无限提交（无 IP/用户维度限流、无频控、无验证码校验、无内容长度与敏感词校验）；客户端重试或用户双击会产生两条内容相同的工单（identity 每次新生成，`add.go:29`），没有业务幂等键。`user_name(20)/title(255)/content(500)` 列宽限制未在应用层校验，超长直接由 PG 抛 `value too long` → 500，且 `Images.URL(255)`、`Accessories.FilePath(500)` 同理。
- **建议**：按用户 + 时间窗做限流（Redis 计数器，本模块已有未使用的 `impl.RedisService`，见问题 23）；约定客户端幂等键（如 `request_id`）并唯一约束去重；用 `protoc-gen-validate` 风格的长度/必填校验（title/content 非空、email/phone 格式与长度）在入口拒绝，而不是让 DB 报错。
#### 22. 图片 URL 与附件 `file_path` 完全信任调用方，无协议/域名/归属校验
- **位置**：`internal/logic/method/add.go:52,64`、`modify.go:65,74`、`test/add.http:11-16`
- **证据**：
```go
// add.go:52,64 —— 客户端给什么就存什么
URL: v.GetUrl(), // 图片URL
FilePath: v.FilePath, // 附件文件路径
// test/add.http:14 —— 官方样例直接使用内网下载地址
"file_path": "http://127.0.0.1:22210/file/download/1"
```
- **影响**：服务端不校验 `javascript:`/`data:` 等危险协议，也不校验域名归属（可指向内网地址或他人上传的文件 ID，样例里就是 `http://127.0.0.1:22210/file/download/1`）。当管理端把 `url`/`file_path` 直接渲染为 `<a href>`/`<img src>` 或由服务端代理下载时，会形成存储型 XSS / SSRF / 越权取文件的组合风险（最终可利用性取决于前端与文件服务实现，属**推测**）。附件与工单之间也没有绑定校验，可以引用不属于自己的文件记录。
- **建议**：只接受 `https://`（或本服务文件网关域名）并做主机白名单；图片/附件改为「先由文件服务上传获得 token，再用 token 换取 URL」的流程，服务端校验归属；渲染侧统一做协议过滤。
#### 23. 缓存依赖初始化后无任何读取点，配置项静默失效（含 Redis/内存缓存/Log/Prometheus/Telemetry）
- **位置**：`internal/impl/impl.go:22-31`、`service/dependencies.go:19-32`、`etc/feedback_prod.yaml:25-42`、`README.md:310-335`
- **证据**：
```go
// impl.go:24-26 —— 初始化了 Redis 与内存缓存
MemorySerice = with.Memory(nil)
RedisService = with.RedisCache(config.Spec.Cache)
// 全模块 grep：impl.RedisService / impl.MemorySerice 只有赋值，没有任何读取点
```
```yaml
# etc/feedback_prod.yaml:25-29 —— 键名与 SDK conf.LogConf(Name/Level/Dir/Console/File/Remote) 完全不同
Log:
ServiceName: {ServiceKey}
Mode: file
Path: logs/{ServiceKey}
```
- **影响**：README:312-318 宣称「反馈列表缓存 5 分钟、详情 10 分钟、用户信息 30 分钟」，代码里没有任何缓存读写（`List`/`Get` 每次都打 DB，见问题 11），Redis 与内存缓存对象纯属死依赖，同时给聚合侧造成「已注入缓存」的错觉（`service/dependencies.go:29-31`）；`Log/Prometheus/Telemetry` 三个配置节对应的字段不在 `SrvConfig`（`config.go:17-25`）中，YAML 解析时被静默忽略——即生产配置里看起来开着的监控与日志其实没有生效。
- **建议**：要么按 README 实现读缓存（列表按「身份+条件」、详情按 identity，写路径失效），要么删除初始化与文档承诺；把 `Log`/`Prometheus`/`Telemetry` 配置节改成 SDK 认可的结构（或新建对应字段）并加启动校验，避免「配置写了但不生效」。
#### 24. `Anonymous` 白名单内容指向本模块不存在的服务，与实现完全脱节
- **位置**：`etc/feedback_dev.yaml:16-23`、`feedback_test.yaml:16-23`、`feedback_prod.yaml:15-22`
- **证据**：
```yaml
# etc/feedback_prod.yaml:15-22 —— 三份配置相同
Anonymous:
Key: anonymous.{Workspace}
Urls:
- feedback.Check.Hello
- feedback.Check.Updates
- feedback.Data.Configure
- feedback.Data.Areas
- feedback.Data.Tags
```
- **影响**：本模块只注册了 `feedback.Method`（`proto/feedback.proto:6`），`feedback.Check.*`/`feedback.Data.*` 在任何地方都不存在（全仓库 grep 无实现），因此这份白名单既不能命中任何真实方法，也向运维传递「本服务有匿名接口」的错误信息；同时该节是映射（`Key`/`Urls`），而 SDK 侧 `MicroServiceConf.Anonymous` 是 `[]string`（`bsm-sdk/core/conf/types.go:23-26`），格式也不兼容（若配置能解析到这一步会 unmarshal 失败）。真实生效的白名单在聚合配置里（`pkgs/all/etc/default_dev.yaml:24-43`，不含 feedback）。
- **建议**：删除该节或改写为 SDK 结构并只列真实需要匿名的 `feedback.Method/*`（按业务确认，例如反馈提交是否允许匿名）；在文档中明确「匿名策略的唯一来源是聚合 `Authorization.Anonymous`」，避免两处声明打架。
#### 25. 分层与可测试性缺陷：logic 直接依赖全局可变单例，无法注入假 DB
- **位置**：`internal/logic/method/*.go`（全部形如 `impl.DBService.`）、`internal/impl/impl.go:13-18`
- **证据**：
```go
// get.go:29 / list.go:35 / delete.go:26 / remark.go:32 —— 直接使用包级全局变量
err = impl.DBService.Preload("Images").Where("identity = ?", in.GetIdentity()).First(record).Error
// impl.go:16
DBService *gorm.DB // 数据库服务
```
- **影响**：业务逻辑没有仓储接口/依赖注入点，唯一的数据访问入口是可变全局变量，导致：①无法在单测中替换 DB（与问题 26 的零测试互为因果）；②`service.Expose` 与 `impl.NewImpl` 两条初始化路径会互相覆盖同一批全局变量（`dependencies.go:19-32`），并发测试或同进程多实例场景下行为不确定；③`Get/Delete/Remark` 三个方法连 `ctx` 都不传递（问题 12），说明入口签名与依赖注入一旦缺失就难以发现。
- **建议**：定义最小仓储接口（`type FeedbackRepo interface{ List(ctx, ...); Get(ctx, identity); ... }`）并在 `Expose` 中注入实现，logic 只依赖接口；把 `impl.DBService` 降级为组合根内部状态。
#### 26. 测试覆盖为零（模块内无任何 `*_test.go`，`test/lint` 目录不存在）
- **位置**：`module/base/feedback/test/`（仅 `add.http`、`rpc/rpc.go`）；`test/rpc/rpc.go:3-23`
- **证据**：
```go
// test/rpc/rpc.go:3-23 —— 整个 main 函数体被注释，无法执行；package 名也不是 main
package rpc
func main() {
/*
... grpc.Dial / c.List() ...
*/
}
```
- **影响**：`gofmt -l .` 与 `go vet ./...` 是本模块唯一的自动化门禁，问题 2（identity 被改写）、问题 4（count=0）、问题 5（列名错）、问题 7（附件 identity 为空）这类「必然发生」的缺陷全部能在单测里被拦住，但当前没有任何测试；`test/add.http` 是手工样例（且样例里的 `type` 字段在 proto 中不存在、JSON 尾随逗号非法，`test/add.http:9,16`）。
- **建议**：至少补齐以下用例并纳入 CI（`go test ./...` + `gofmt -l` + `go vet`）：
1. `Add` 全字段落库（含 category/agency/附件），断言附件 identity 非空、`Get` 能取回附件（覆盖问题 6/8）；
2. `Modify` 前后 `identity` 不变、`item_identity` 指向正确、子表不重复（问题 2/7）；
3. 越权矩阵：A 用户对 B 用户的 identity 执行 Get/Modify/Delete/Remark 全部拒绝（问题 1/10）；
4. `List` 分页：`page=1/2/末页/超界` 的 `count` 与 `len(list)`；带 `user_name`/`status`/`category` 过滤（问题 4/5）；
5. 写接口对不存在 identity 返回 `ErrRecordNotFound`（问题 19）；
6. 状态常量与非法流转（问题 20）、超长字段与非法 URL 的入参校验（问题 21/22）；
7. 网关契约：`POST /feedback.Method/Add` 与 `/rpc/feedback/Method/Add` 的 200/401 期望值（问题 9），以及 `Expose` 传 nil 依赖时返回错误而非 panic（问题 18）。
### P3
#### 27. README 大量内容与实现不符（端口、目录、命令、缓存、健康检查、Docker/K8s）
- **位置**：`README.md:36,56-59,164-169,184,217-237,262-263,268-269,310-335,432-455`
- **证据**：
```markdown
<!-- README:164-169 表格标注端口 12101；README:184 swagger 在 12102 -->
| Method | Add | 添加反馈 | 12101 |
- **本地**: http://localhost:12102/feedback.swagger.json
<!-- README:217-221 -->
# 运行所有测试
go test ./...
# README:269
go run cmd/main/main.go migrate
```
- **影响**：实际配置端口是 12210（`etc/feedback_prod.yaml:2`）、聚合入口是 12000/12001（`pkgs/all/etc/default_dev.yaml:5,8`）；`swagger/`、`scripts/`、`Makefile`、`Dockerfile`、`docker-compose.yml`、`k8s-deployment.yaml`、`.githooks` 全部不存在（模块根目录仅有 `cmd etc internal pb proto service test`）；`go test ./...` 无测试可跑；`migrate` 子命令不存在（问题 16）；README:436-455 的建表 DDL 与模型不一致（缺 `deleted_at`，`passport_id` 类型、索引均未提及）。README:19 宣称「完善的安全: 输入验证」，与问题 1-3、21-22 直接矛盾。
- **建议**：按代码实际情况重写 README（端口/路径/命令/目录/DDL），并删掉所有未实现能力的宣称；把 `wiki/api/04-feedback.md` 与 README 的接口表合并为单一份生成文档。
#### 28. `etc/feedback.yaml` 是死配置；三份环境配置雷同且与 `.builds` 重复
- **位置**：`etc/feedback.yaml:1-6`、`etc/feedback_{dev,test,prod}.yaml`、`.builds/etc/feedback_prod.yaml`
- **证据**：
```yaml
# etc/feedback.yaml:1-6 —— 文件名不含 _<mode>，conf.New 只读 feedback_{mode}.yaml
Name: feedback.rpc
ListenOn: 0.0.0.0:8080
Etcd:
Key: feedback.rpc
```
```go
// bsm-sdk/core/conf/new.go:35
cfp := fmt.Sprintf("%s_%s.yaml", strings.ToLower(srvKey), env.Runtime.Mode)
```
- **影响**：`feedback.yaml` 永远不会被加载（`BSM_RuntimeMode` 只会拼出 `feedback_dev/test/prod.yaml`），且其中的 `Key: feedback.rpc` 与其它文件声明的 `service.{Workspace}.{ServiceKey}.rpc` 命名规则互相矛盾；dev/test/prod 三份文件除 DSN 外几乎逐字相同（dev 与 test 的差异仅在 DB 主机/库名），prod 与 `.builds/etc/feedback_prod.yaml` 完全重复，任何配置修改都要同步多处，极易漏改（问题 3 的密钥正是这样泄漏的）。
- **建议**：删除 `etc/feedback.yaml`；用模板 + 环境变量（`os.ExpandEnv` 已支持）生成各环境配置，密钥全部外置；`.builds/etc` 下不发密钥文件。
#### 29. 时间字符串不带时区；`ListRequest` 暴露了多个未实现字段
- **位置**：`internal/logic/method/ref.go:24-25`、`bsm-sdk/core/vars/time.go:6`、`proto/feedback.proto:19,23-25`
- **证据**：
```go
// ref.go:24-25 —— 布局串不含时区
CreatedAt: item.CreatedAt.Format(vars.YYYY_MM_DD_HH_MM_SS),
// bsm-sdk/core/vars/time.go:6
YYYY_MM_DD_HH_MM_SS string = "2006-01-02 15:04:05"
```
- **影响**：返回的时间是 `2024-01-01 10:00:00` 形式的裸本地时间，依赖 DSN 里的 `TimeZone=Asia/Shanghai` 与进程 TZ 一致才能正确解释（聚合库 DSN 也写了 Asia/Shanghai，属**推测**其一致）；跨时区客户端或夏令时场景无法还原为绝对时刻，排序与展示也容易错位。同时 `ListRequest.user_identity/email/phone/store_identity`（proto 字段 3/7/8/9）在逻辑中完全未使用（问题 5），文档却把它们列为可用筛选条件。
- **建议**：统一返回 RFC3339（带偏移）或明确 `_at` 字段为 UTC+8 并在文档标注；未实现的入参字段从 proto 删除或补齐实现。
#### 30. 死代码与空壳文件
- **位置**：`proto/const.proto` / `pb/const.pb.go`（97KB）、`cmd/cli/main.go`、`test/rpc/rpc.go`、`internal/server/new.go:17`
- **证据**：
```go
// cmd/cli/main.go:5-7
func main() { log.Println("Hello World!") }
// internal/server/new.go:17 —— grpcConns 声明后从未使用（既非连接池也无任何读写）
grpcConns map[string]*grpc.ClientConn // 连接池
```
- **影响**：`feedback.proto` 未 `import` 任何文件（`proto/feedback.proto:1-3`），`const.proto` 里全是 cms/order/social/market 等他域消息（`proto/const.proto:7-315`），本模块无任何引用（grep `pb.Empty|pb.StdIicuds|pb.IDRequest` 无命中），却被打包进每个使用者的二进制并出现在文档生成流程中；`cmd/cli` 是 Hello World，`test/rpc/rpc.go` 整段注释，`grpcConns` 是无用字段。
- **建议**：删除 `proto/const.proto` 与 `pb/const.pb.go`、`cmd/cli`、`grpcConns`；`test/rpc/rpc.go` 要么恢复为可运行的冒烟脚本（`package main` + 真实请求）要么删除。
#### 31. 魔法数字、拼写与仓库外相对依赖
- **位置**：`list.go:29-31,55`、`add.go:36`、`internal/impl/impl.go:17`、`go.mod:69`
- **证据**：
```go
// list.go:29-31,55 —— 10/50/0 为裸字面量
if size < 1 || size > 50 { in.Size = 10 }
if status != 0 { sess = sess.Where("status = ?", status) }
// internal/impl/impl.go:17 —— 拼写少了 v，且该字段无读取点
MemorySerice *cache.Cache // 内存缓存服务
// go.mod:69
replace git.apinb.com/bsm-sdk/core => ../../../../../bsm-sdk/core
```
- **影响**：分页上限、默认页大小、状态值散落在逻辑里，与 `models` 的注释（1 未处理/2 已处理）没有单一事实来源，修改时容易漏改；`MemorySerice` 拼写错误会在重命名/检索时造成困扰；`go.mod` 的 `replace` 指向仓库外相对路径（`D:\work\bsm-sdk\core`），意味着在干净环境中仅凭本仓库无法构建（构建脚本依赖外部 checkout + `go.work`），CI/新同事环境易踩坑。
- **建议**：把分页与状态值提为常量（`const DefaultPageSize=10; MaxPageSize=50; StatusPending=1; StatusHandled=2`）；统一改名为 `MemoryService`（同时改 `internal/impl` 与所有引用）；依赖统一用 `go.work` 管理，`go.mod` 不保留穿透仓库的相对 `replace`。
#### 32. 代码注释与实现不符（误导后续维护者）
- **位置**：`internal/logic/method/delete.go:25`、`list.go:34,70`、`README.md:16,19,320`
- **证据**：
```go
// delete.go:25 —— 事实是只软删主表，子表没有任何级联（模型无 OnDelete/约束）
// 删除记录（GORM会自动处理关联的图片和附件删除）
err = impl.DBService.Where("identity = ?", in.GetIdentity()).Delete(new(models.FeedbackItem)).Error
// list.go:34 —— 声称预加载"图片信息"，实际与 ref.go:38-45 的附件需求不匹配（问题 8）
// 构建查询会话，预加载图片信息
```
- **影响**：`Delete` 之后 `feedback_images`/`feedback_accessory` 中的行仍然存在（只是主表被软删），与注释和 README:16「Redis 缓存 + 数据库优化」形成误导；维护者据此认为级联已处理，会放弃补偿清理，长期累积孤儿数据（在主表记录被软删后无法通过 API 发现）。
- **建议**：修正注释并把级联删除显式实现（事务内软删子表，或改为硬删并加 `ON DELETE CASCADE` + 定期清理任务）；同步修正 README 中所有与实现不符的能力描述。
## 4. 推荐优化方案
1. **授权闭环（目标：所有写读接口都基于身份做归属判定）**：做法：在 `Get/Modify/Delete/Remark` 统一 `service.ParseMetaCtx`，抽出 `ownedQuery(ctx)` 把 `passport_identity` 条件注入所有按 identity 的查询/更新/删除；管理端另设明确角色（`ParseOptions.RoleValue`）；`List` 改为「先按身份收窄，再叠加机构/分类过滤」，`auth.Identity` 为空直接拒绝。影响面：`internal/logic/method/*.go`、可选新增 `internal/logic/authz`。风险：中；需与前端/管理后台确认角色与机构口径，避免误拦管理端。
2. **修掉两处必然损坏（目标：Modify 不再改写主键，子表一次写入）**：做法：`Modify` 用 `map[string]any`/`Select` 更新白名单字段且不带 `Identity`；`Omit(clause.Associations)` 关闭隐式关联写；附件补 `utils.UUID()`；整段包 `Transaction`。影响面：`modify.go`、`add.go`（对照补齐 category/agency）、`ref.go`（回传缺字段）。风险：低-中；历史已被改写的 identity 需要用 `feedback_images.item_identity` 反查修复（一次性数据订正脚本）。
3. **查询与分页正确性（目标：count 正确、过滤列正确、子表可查）**：做法：拆开 `Count` 与 `Find`；`username` → `user_name`；`Preload("Accessories")`；补齐 `email/phone` 过滤或删除字段。影响面：`list.go`、`get.go`。风险：低；属于可立即上线的修复。
4. **索引与分页性能（目标：从全表扫描到索引扫描 + 稳定上限）**：做法：提交可执行 DDL（`feedback_images(item_identity)`、`feedback_accessory(item_identity)`、`feedback_item(passport_identity, created_at)`、`feedback_item(agency)`），`List` 走 keyset 分页 + `WithContext` 超时。影响面：新增 `migrations/`、`list.go`、`models/*`。风险：中；大表建索引需用 `CONCURRENTLY` 并在低峰执行。
5. **密钥与配置治理（目标：仓库/产物内零凭据，配置真正生效）**：做法：轮换生产口令并清理 git 历史；DSN/Redis/Etcd 走环境变量或密钥管理；prod 使用 `sslmode=require` + 最小权限账号；`etc/*.yaml` 重写为 SDK 认可的 `Service/Port/Databases/Cache/MicroService/Log` 结构并加 fail-fast 校验（拒绝 `CHANGE_ME`/`sslmode=disable`）；删除 `etc/feedback.yaml`。影响面：`etc/*`、`.builds/etc/*`、`scripts/build-all-linux.sh`、`internal/config/config.go`。风险：中；需与运维约定注入方式，避免上线即失败。
6. **入口统一（目标：独立与聚合行为一致、网关不再 404）**：做法：`internal/server.New()` 内建 `Mux` 并注册 `RegisterMethodHandlerServer`，`cmd/main` 与 `service.Expose` 走同一函数；`Expose` 校验 nil 依赖并返回 error；独立入口装配与聚合一致的鉴权/recovery 拦截器。影响面：`internal/server/new.go`、`cmd/main/main.go`、`service/{expose,dependencies}.go`。风险：中；需回归两条部署路径的启动自检。
7. **可观测性与生命周期（目标：故障可定位、可优雅重启）**：做法：接入 SDK logger 并对 email/phone 掩码、生产关闭 GORM `Debug`；注册 gRPC health、接上或删除 APM/Prometheus；实现信号处理 + 关停编排；reflection 改为配置开关。影响面：`internal/impl/impl.go`、`internal/logic/*`、`cmd/main/main.go`、`internal/server/new.go`。风险：低。
8. **数据治理与状态机（目标：状态语义唯一、可审计）**：做法：把处理状态从 `Std_IICUDS.Status` 剥离命名，定义状态常量与合法迁移、记录处理人（新增 `handler_identity`/`handled_at`，目前包里没有任何处理人字段，`proto/feedback.proto:34-51` 与模型均无），`Add` 不允许设置处理状态；补迁移。影响面：`internal/models/*`、`proto/feedback.proto`、`logic/*`、`wiki/api/04-feedback.md` 重新生成。风险：中；涉及 DDL 与前端契约变更。
9. **限流与防刷（目标：提交入口不可被滥用）**：做法：用已初始化但闲置的 Redis 做「用户+IP」维度的滑动窗口限流、幂等键去重（唯一约束）、入参长度与内容校验。影响面：`add.go`、新增 `internal/logic/limit`、`internal/impl`。风险：低-中；阈值需灰度确认。
10. **测试与 CI 门禁（目标：上述修复可回归）**：做法：按问题 26 的清单补单测与网关集成测试，CI 跑 `go test ./...`、`gofmt -l .`、`go vet ./...`（后两者当前已通过，可直接作为基线）。影响面：`test/`、模块 CI。风险：低。
## 5. TODO 清单
- [ ] **P0-1** 在 `Get/Modify/Delete/Remark` 接入 `ParseMetaCtx` 并统一按 `passport_identity` 做归属过滤（管理端走显式角色）｜验收：用户 A 用 B 的 identity 调这四个方法全部返回权限/未找到错误，且 A 的 `List` 只返回自己的工单｜涉及：`module/base/feedback/internal/logic/method/get.go:19`, `delete.go:19`, `remark.go:19`, `modify.go:24`, `list.go:37`
- [ ] **P0-2** `Modify` 更新语句不再写入 `identity`，改用 `Select`/map 白名单字段并 `Omit(clause.Associations)`｜验收：单测断言 `Modify` 前后 `identity` 不变、无重复图片行、`item_identity` 始终指向当前 identity｜涉及：`module/base/feedback/internal/logic/method/modify.go:35`, `modify.go:89`
- [ ] **P0-3** 轮换生产 DB/Redis 口令、清理 git 历史中凭据，并把 DSN 改为环境变量注入 + `sslmode=require`｜验收：`grep -rn "MakeW2023" .` 与构建产物中均无凭据；启动时若 DSN 含 `CHANGE_ME`/`sslmode=disable` 直接失败｜涉及：`module/base/feedback/etc/feedback_prod.yaml:4`, `.builds/etc/feedback_prod.yaml:4`, `scripts/build-all-linux.sh:100`
- [ ] **P1-4** `List` 拆分 `Count` 与 `Find` 两条语句｜验收：`page=2` 返回的 `count` 等于真实总数（单测覆盖 page=1/2/末页/超界）｜涉及：`module/base/feedback/internal/logic/method/list.go:71`
- [ ] **P1-5** 修正 `username` → `user_name`，并对未实现的筛选字段（email/phone/store_identity/user_identity）补实现或从 proto 删除｜验收：带 `user_name` 的 `List` 正常返回 200 且结果正确；proto 中不存在「文档可见但未实现」的字段｜涉及：`module/base/feedback/internal/logic/method/list.go:50`, `proto/feedback.proto:19`
- [ ] **P1-6** `Add`/`Modify` 补齐 `category`/`agency`（及 `store_identity` 落列），`convert()` 回传 `user_identity`/`agency`/`store_identity`｜验收：`Add` 后 `Get` 能读回同值 category/agency，`List` 按 category/agency 能筛到该记录｜涉及：`module/base/feedback/internal/logic/method/add.go:35`, `modify.go:43`, `ref.go:14`
- [ ] **P1-7** `Modify` 用事务包住「删子表→更新主表→重建子表」，附件补 `utils.UUID()`，并消除重复写入｜验收：2 个附件的 `Modify` 成功且附件 identity 非空；注入第 3 步失败的测试断言全部回滚、无重复行/唯一键冲突｜涉及：`module/base/feedback/internal/logic/method/modify.go:70`, `modify.go:79`, `modify.go:96`
- [ ] **P1-8** `Get`/`List` 增加 `Preload("Accessories")`｜验收：`Add` 带附件后 `Get`/`List` 返回同名附件｜涉及：`module/base/feedback/internal/logic/method/get.go:29`, `list.go:35`
- [ ] **P1-9** 统一入口注册路径：`internal/server.New()` 内建 `Mux` 并注册网关 handler，`cmd/main` 与 `service.Expose` 复用；重写 `etc/feedback_*.yaml` 为 SDK 结构｜验收：独立启动后 `POST /feedback.Method/List`（带合法 JWT）返回 200 而非 404，且配置解析不再 fatal、端口与配置文件一致｜涉及：`module/base/feedback/internal/server/new.go:16`, `cmd/main/main.go:37`, `module/base/feedback/etc/feedback_prod.yaml:1`
- [ ] **P1-10** `List` 不再因 `agency` 跳过身份过滤；`auth.Identity` 为空时拒绝｜验收：传入任意 `agency` 也只返回本人工单；空 identity 令牌返回权限错误｜涉及：`module/base/feedback/internal/logic/method/list.go:38`
- [ ] **P1-11** 提交三张表的索引 DDL 并把列表改为 keyset 分页｜验收：`EXPLAIN` 显示 `feedback_images(item_identity)` 与 `feedback_item(passport_identity, created_at)` 走索引；第 100 页查询耗时与第 1 页同量级｜涉及：`module/base/feedback/internal/models/feedback_images.go:13`, `feedback_accessory.go:13`, `feedback_item.go:22`
- [ ] **P2-12** 所有 DB 调用改为 `WithContext(ctx)` 并加超时/重试｜验收：客户端取消后查询在超时内中断（慢查询测试验证）｜涉及：`module/base/feedback/internal/logic/method/list.go:71`, `get.go:29`, `modify.go:89`
- [ ] **P2-13** gRPC 增加 recovery 拦截器并为 nil 依赖 fail-fast｜验收：注入 panic 后进程存活且返回 `Internal`；`Expose` 传 nil DB/GRPC/Gateway 时返回明确错误｜涉及：`module/base/feedback/internal/server/new.go:23`, `service/expose.go:20`, `service/dependencies.go:19`
- [ ] **P2-14** 接入结构化日志与 gRPC health，错误包装不外泄 SQL 文本；reflection 改配置开关｜验收：生产日志无 SQL 原文、`/health` 或 gRPC health 返回 SERVING、生产 `grpcurl list` 失败｜涉及：`module/base/feedback/internal/server/new.go:35`, `module/base/feedback/internal/logic/method/modify.go:90`
- [ ] **P2-15** 生产关闭 GORM `Debug`（显式传 `SqlOptions`），并对 email/phone 做日志掩码｜验收：生产日志中不再出现完整 SQL 与手机号/邮箱明文｜涉及：`module/base/feedback/internal/impl/impl.go:28`
- [ ] **P2-16** 提供可执行迁移（三张表 + `deleted_at` + 索引），删除 README 中不存在的 `migrate` 命令或实现它｜验收：从空库按仓库步骤执行后所有接口可用；`grep feedback_item` 能找到 DDL 文件｜涉及：`module/base/feedback/internal/models/feedback_item.go:27`, `README.md:269`
- [ ] **P2-17** 实现信号处理与真正的优雅退出（关停 gRPC/DB/Redis/Etcd）｜验收：`SIGTERM` 后在途请求完成、进程 5s 内退出｜涉及：`module/base/feedback/cmd/main/main.go:42`
- [ ] **P2-18** `Expose`/`applyDependencies` 对 `DB/GRPC/Gateway/Cache` 做 nil 校验并返回错误，不再丢弃 `server.New` 返回值｜验收：任一依赖为 nil 时聚合启动即失败并打印原因，而非首个请求 panic｜涉及：`module/base/feedback/service/expose.go:20`, `service/expose.go:23`, `service/dependencies.go:19`
- [ ] **P2-19** 三个写接口检查 `RowsAffected` 并在 0 行时返回 `ErrRecordNotFound`；备注/状态用显式列更新以支持清空｜验收：对不存在 identity 的 Delete/Remark/Modify 返回未找到；可将 remark 置空｜涉及：`module/base/feedback/internal/logic/method/delete.go:26`, `remark.go:32`, `modify.go:89`
- [ ] **P2-20** 处理状态与 `Std_IICUDS.Status` 解耦，定义状态常量与合法迁移，`Add` 禁止直接设置处理状态｜验收：`Add` 传 `status=2` 被拒或被忽略；非法流转被拒绝｜涉及：`module/base/feedback/internal/models/feedback_item.go:18`, `module/base/feedback/internal/logic/method/add.go:36`
- [ ] **P2-21** 提交入口加限流 + 幂等键 + 入参长度/格式校验｜验收：超过阈值的提交被拒；重复提交同一幂等键只产生一条工单；超长 title/content 返回参数错误而非 500｜涉及：`module/base/feedback/internal/logic/method/add.go:19`, `internal/models/feedback_item.go:15`
- [ ] **P2-22** 校验图片 `url` 与附件 `file_path`（协议/主机白名单 + 归属）｜验收：`javascript:`/内网地址/他人文件路径被拒绝｜涉及：`module/base/feedback/internal/logic/method/add.go:52`, `add.go:64`
- [ ] **P2-23** 缓存与配置治理：实现读缓存或在文档中删除承诺；`Log/Prometheus/Telemetry` 改 SDK 结构并加启动校验｜验收：代码中明确区分为「已实现缓存」或「无缓存」，配置项被实际读取（可打印生效值）｜涉及：`module/base/feedback/internal/impl/impl.go:24`, `etc/feedback_prod.yaml:25`
- [ ] **P2-24** 删除或改写 `Anonymous` 白名单（当前指向不存在的 `feedback.Check/Data` 服务，且映射格式与 SDK `[]string` 不兼容）｜验收：配置中只列真实需要匿名的方法，或该节被删除并在文档说明匿名策略唯一来源是聚合 `Authorization.Anonymous`｜涉及：`module/base/feedback/etc/feedback_prod.yaml:15`, `module/base/feedback/etc/feedback_dev.yaml:16`
- [ ] **P2-25** 引入仓储接口，logic 不再直接使用全局 `impl.DBService`｜验收：单测可用假仓储替换 DB 并覆盖全部 6 个方法｜涉及：`module/base/feedback/internal/logic/method/get.go:29`, `module/base/feedback/internal/impl/impl.go:16`
- [ ] **P2-26** 按问题 26 的清单补齐测试并纳入 CI（`go test ./...` + `gofmt -l` + `go vet`）｜验收：上述 7 类用例全部存在且通过；覆盖率纳入门禁｜涉及：`module/base/feedback/test/rpc/rpc.go:3`, `module/base/feedback/test/add.http:9`
- [ ] **P3-27** 按实现重写 README（端口/目录/命令/健康检查/缓存/DDL），删除不存在的 swagger/Makefile/Docker/K8s 描述｜验收：README 中每条命令与路径都能在仓库中找到对应实现｜涉及：`module/base/feedback/README.md:164`, `README.md:184`, `README.md:269`, `README.md:438`
- [ ] **P3-28** 删除死配置 `etc/feedback.yaml`，并用模板 + 环境变量消除 dev/test/prod 与 `.builds/etc` 之间的重复｜验收：`conf.New` 只会读取真实存在的 `feedback_{mode}.yaml`，配置变更只需改一处｜涉及：`module/base/feedback/etc/feedback.yaml:1`, `module/base/feedback/etc/feedback_prod.yaml:1`, `scripts/build-all-linux.sh:97`
- [ ] **P3-29** 时间返回带时区（RFC3339 或显式标注 UTC+8），并把 `ListRequest` 中未实现的筛选字段补实现或删除｜验收：响应时间字符串含时区；proto 中不存在「文档可见但未实现」的字段｜涉及：`module/base/feedback/internal/logic/method/ref.go:24`, `module/base/feedback/proto/feedback.proto:19`
- [ ] **P3-30** 删除死代码：`proto/const.proto`/`pb/const.pb.go`(97KB)、`cmd/cli`、`internal/server/new.go:17` 的 `grpcConns`；`test/rpc/rpc.go` 恢复为可运行冒烟脚本或删除｜验收：`grep -rn "const.pb\|grpcConns\|Hello World" module/base/feedback` 无残留业务引用｜涉及：`module/base/feedback/proto/const.proto:7`, `module/base/feedback/internal/server/new.go:17`, `module/base/feedback/cmd/cli/main.go:6`
- [ ] **P3-31** 提取分页/状态常量为具名常量、修正 `MemorySerice` 拼写、去掉 `go.mod` 中穿透仓库的相对 `replace`｜验收：逻辑中无裸状态/分页字面量；`grep -rn "MemorySerice" module/base/feedback` 无命中；干净环境下可构建｜涉及：`module/base/feedback/internal/logic/method/list.go:29`, `module/base/feedback/internal/impl/impl.go:17`, `module/base/feedback/go.mod:69`
- [ ] **P3-32** 修正与实现不符的注释（`delete.go:25` 声称级联删除、`list.go:34` 预加载描述），并让行为与注释一致（事务内软删子表或改为级联硬删）｜验收：`Delete` 后子表无孤儿行；注释与代码一致｜涉及：`module/base/feedback/internal/logic/method/delete.go:25`, `module/base/feedback/internal/logic/method/list.go:34`
## 6. 审计摘要（供汇总使用）
- 问题数：P0=3 P1=8 P2=15 P3=6
- 最高风险（一句话）：`Get`/`Delete`/`Remark` 只验「已登录」不验归属（`get.go:19`、`delete.go:19`、`remark.go:19`，独立入口更是连登录都不需要），任意调用方可读取他人反馈的 email/phone、改写处理状态或删除他人工单；同时 `Modify` 用新 UUID 覆盖 `identity`（`modify.go:37,89`）会**必然**让工单失联、子表脱钩，两者叠加使数据既被越权改动又无法追溯修复。
- 最优先 3 个动作：1) 给 `Get/Modify/Delete/Remark` 加身份与归属校验（P0-1）；2) 修掉 `Modify` 覆盖 `identity` 与关联双写/无事务（P0-2、P1-7）；3) 轮换并外置生产库口令、清理仓库与 `.builds` 产物中的凭据（P0-3）；紧随其后是 `Count` 置 0（P1-4）与 `username` 列名错误（P1-5）这类可立即上线的小修。
- 未能覆盖/无法验证的部分：未运行服务、未连接真实 PostgreSQL/Redis/Etcd，未 dump 线上表结构，因此「`feedback_images.identity` 唯一索引是否存在」「线上 `feedback_item` 是否有遗留 `username` 列」「`ORDER BY created_at` 是否走索引」均为静态推断（依赖该前提的结论已在正文标注「推测」）；`pb/feedback.pb.go`(1310 行) 与 `pb/const.pb.go` 未逐行阅读（仅做接口与消息一致性比对）；未审计 CI/发布流水线与线上真实配置是否被环境变量或 etcd 覆盖；SDK（`bsm-sdk/core`）与聚合服务（`pkgs/all`、`pkgs/ecmall`）仅按需读取相关片段，其中 SDK 侧问题（`with.Databases` 默认 `Debug:true`/`IsAutoMigrate:false`、`service.Start()` 用 `select {}` 阻塞、`env` 硬编码兜底 JWT 密钥 `Cblocksmesh2022C`）归属 SDK 仓库，本报告仅在与本模块调用点相关处引用。
Reference in New Issue View Git Blame Copy Permalink