蛛网之上 Above the Web
GitHub ↗

发布于 更新于 约 4 分钟读完 · 1,375 字

本文目录 9 节
  1. 一句话总结
  2. 背景与事实
  3. 四条可复用 insight
  4. 1. 反馈渠道匿名兜底律
  5. 2. 零迁移建表(顺着项目既有惯例)
  6. 3. 422 探针:线上验证不留脏数据
  7. 4. 模式考古先行(无框架大文件项目)
  8. 两条顺手教训
  9. 关联文档

内测反馈渠道上线 · 匿名兜底与 422 探针验证

入档:2026-07-24 来源:PB Arena(pb.tiaozhuxiansheng.com)问题反馈渠道开发,单会话完成 5 文件 +437 行并部署上线(pb-arena 仓库 commit 4e85066) 状态:已上线并线上验证;四条 insight 均有本次实测支撑

一句话总结

给内测产品加反馈渠道,产品上要让”登录不了的人”也能反馈(匿名兜底+限流补偿),工程上先做模式考古照抄现有惯例,上线后用一发”必失败的校验请求”(422 探针)验证路由生效而不留脏数据。

背景与事实

  • 任务:PB Arena 内测需要 bug 反馈渠道——用户点按钮弹问卷,填写提交,管理员后台可见可处理。上一会话中断,本会话恢复执行。
  • 交付:悬浮按钮+问卷弹窗(前端)、feedback 表 + POST /api/feedback + 管理端查看/标记接口(后端)、运营后台反馈面板。
  • 验证链:node --check 语法 → scratch 库起服务全链路自测(匿名提交 201 / 空标题 422 / 连续提交 429 / 管理员列表筛选与标记) → 部署 → 线上 grep 新 UI + 422 探针确认路由。
  • 插曲:GitHub push 连续两次 TLS 握手失败;deploy.ps1 的 Windows scp lost connection;最终 Git Bash ssh/scp 部署成功,push 稍后重试即通。

四条可复用 insight

1. 反馈渠道匿名兜底律

“登录不了”本身就是最需要被反馈的 bug——反馈接口若要求登录,就把最关键的反馈者挡在门外。 正解=可选认证:带 token 就关联账号,没有就记”匿名用户”;滥用风险不靠登录墙,靠双层限流补偿(本次:匿名按 IP 10 分钟 5 条,登录用户两次间隔 30 秒)。同理适用于一切”报障/求助”类入口:入口的可用性要求必须低于它所服务的故障面。

2. 零迁移建表(顺着项目既有惯例)

项目把全量 schema 写成 CREATE TABLE IF NOT EXISTS 常量、每次启动执行——这种惯例下加新表=往 schema 常量里添一段,线上老库重启自动补表,零迁移脚本。动手前值得先确认项目的建表/迁移惯例,能白拿的机制不要自己再发明一套。

3. 422 探针:线上验证不留脏数据

上线后要独立验证新接口真的活了,但往生产库提交真数据会污染后台。正解=发一个”必然被业务校验拒绝”的请求(如空 body),看到 422 即三证合一:路由已部署、代码已重启生效、校验逻辑在工作;而 404/503 立刻暴露没部署成功。 零脏数据,一条 curl 收口。是 交付前实测证伪律_v1 的”最小探针”在交付后线上核查场景的变体。

4. 模式考古先行(无框架大文件项目)

目标项目是无框架 Node(99KB database.js + 53KB 手写路由 app.js)。动手前先 grep 出最相似的既有功能(聊天消息、审计日志)把完整模式摸清:路由字符串匹配写法、publicXxx 序列化层、限流 Map、审计日志钩子——然后逐层照抄。架构决策成本≈0,437 行一次通过零返工。 在惯例强的存量代码库里,“考古 30 分钟”比”按自己习惯写”快且不留风格裂缝。

两条顺手教训

  • push 失败 ≠ 不能部署:部署链路是本地 HEAD 打包 scp 直传服务器(E:\pb-arena\deploy\deploy.ps1,库外资产),与 GitHub 完全解耦;GitHub 抽风时先上线再补 push。自动化会话里 Windows scp/ssh 不可靠,用 Git Bash 的 ssh/scp。
  • 恢复中断会话,第一真相源是 git status:工作树干净=上个会话没留半成品,直接从头做;不要靠猜测或翻聊天记录复原状态。

关联文档

类型/平台工程