xiaotutongxue

Files

T

lovife d8463a051f verify(storage): 七牛云接通并验证通过 —— 对象存储这块完成

根因就是那个"多出来的一个字符"：secret-key 原来是 **41** 字符，
而七牛的 AK/SK 都是 40 字符的 URL 安全 base64。用户重新复制后（SK 40 字符）一切正常。

排查方式值得记：没有凭一次失败下结论，而是做了三次互相独立的验证 ——
  ① 我手写的管理 API 签名（可能是我的 bug，不能作数）
  ② 应用启动自检里的**七牛官方 SDK** 的 uploadToken
  ③ 一个**能把原因分开**的调用：BucketManager.stat(bucket, 一个一定不存在的键)
     612 = 鉴权通过（只是文件不存在）/ 401 = 密钥无效 / 631 = bucket 名不对
三次一致指向"密钥无效"，所以给用户的结论是确定的，而不是"可能是配置问题"。

验证证据：
  启动自检通过：写入 → 存在 → 读回 → 删除 全部正常（provider=qiniu）
  材料存储：七牛云（bucket=tools-matrix domain=https://file.tools.coding.design）
  e2e-m1-storage.py 16/16：
    · 签名链接形如 .../xiaotutongxue/std/1/17/%E5%BC%A0%E5%90%8C%E5%AD%A6-…?e=…&token=…
    · **中文对象键逐段编码正确**（就是设计时专门防的那个坑）
    · 签名链接下载回来是真 JPEG、非空
    · **不带签名的裸地址被拒（401/403）→ 空间确实私有，签名在起作用**
    · 对象键带 xiaotutongxue/ 前缀
    · **原始件字节与上传的一模一样**
  全量回归 370 条断言、0 失败（此时 provider=qiniu，文件真的进七牛）

顺带修掉一条"写死了存储位置"的 E2E 断言：e2e-m3-file.py 原来断言
  「原始文件真的存在磁盘上」，切到七牛后整片变红，而那看起来像代码坏了。
改成通过产品接口把文件取回来比字节（GET /mp/files/{id}/url → 下载）：
  对两种 provider 都成立，而且比原来更强（顺带验了签名链接、私有访问、内容完整性）。
教训：**在"可替换的实现"上写断言，等于把测试绑死在一种实现上。**

状态：backend/application-local.yml 已是 provider: qiniu（密钥 gitignore、不进 jar）；
生产用 XT_STORAGE_PROVIDER=qiniu + QINIU_ACCESS_KEY/QINIU_SECRET_KEY。

2026-09-29 14:52:51 +08:00

feat(material): M1-04 材料项定义与内置模板

2026-09-29 09:42:08 +08:00

prototype

docs: 产品文档与交互原型（P1-P7 交付物）

2026-09-28 16:19:19 +08:00

00-交付计划.md

docs: 产品文档与交互原型（P1-P7 交付物）

2026-09-28 16:19:19 +08:00

01-客户与机构确认函.md

docs: 产品文档与交互原型（P1-P7 交付物）

2026-09-28 16:19:19 +08:00