xiaotutongxue

lovife/xiaotutongxue

Fork 0

Commit Graph

Author	SHA1	Message	Date
lovife	57bf39d5a1	feat(notify,log): 催报分钟级限流 + 学生微信登录写登录日志（两处合规补漏）一、催报分钟级限流（F-29，契约 §3「10 次/分钟/任务」此前未实现） · UrgeService 加 Redis 计数：定向与一键催报共用，超限 42901 且话说清等多久、24h 去重还在（去重防「学生被重复催」，限流防「老师连点把系统打爆」—— 两件事）；限流放在「确实有活可干」之后（空结果连点不计数） · Redis 不可用时放行不瘫痪（限流是保护，不是业务前提）二、学生微信登录也写 sys_login_log（F-31 —— 此前只有 PC 账号密码登录留痕，按 §13.4 查「学生登录记录」永远为空，合规缺口） · 新增 WechatLoginLogger：小程序登录（MpLoginService）与 H5 授权回调/ 打桩登录（MpH5AuthController）三条路径都写 · login_type=2 与 DDL 注释对齐（1 PC 2 小程序 3 开放接口）；H5 与小程序共用 2（DDL 只定义到 3，不造新值），要区分看 userAgent —— 字段里本来就带着 · 写失败不影响登录（日志表满了不能没人能登录）；不记 code/openid 验证：e2e-m5-urge → 42/42（新增「连点第 11 次被限流」断言，先清计数保证确定性） e2e-m3-h5-auth → 24/24（新增「两次 stub-login 各留一条 login_type=2」断言，清理时连登录日志一起清）	2026-09-30 12:38:48 +08:00
lovife	30c3714d35	test(scripts): 36 个 E2E 与 6 个机械校验工具（1548 条断言）+ 一键交付自检新增：check-api-parity（契约 121 接口 ↔ 控制器，自带「必须恰好 121」自检）、 check-entity-columns（基类要求的列 vs 迁移建表列，F-35 那个坑踩了四次之后上的工具）、 check-manual（手册引用的错误码与提示文案对得上代码）、check-test-profile（test profile 真起一次）、 e2e-prodguard、load-test（四场景、按端点分别统计）、verify-all（一条命令跑完交付自检）、 dev-seed-audit（界面验收用的演示数据），以及 M1~M9 各轮 E2E。压测抓到一个真缺陷并修掉（F-92）：门禁 IP 限流原来计「所有请求」，于是一个班连同一个 WiFi 时 60 个不同学生同时核验只过了 20 个 → 改为只计失败 + 单独的成功上限，20/60 → 60/60。度量工具的偏差会伪装成产品缺陷（F-60/F-77/F-97），所以每个脚本都断言「动作自己的结论字段」（submitted / created / canExport），而不是 HTTP 200 + code 0。验证：verify-all.py --quick 5/5；--with-e2e 见 docs/09 §8。	2026-09-30 09:02:57 +08:00

Author

SHA1

Message

Date

lovife

57bf39d5a1

feat(notify,log): 催报分钟级限流 + 学生微信登录写登录日志（两处合规补漏）

一、催报分钟级限流（F-29，契约 §3「10 次/分钟/任务」此前未实现）
  · UrgeService 加 Redis 计数：定向与一键催报共用，超限 42901
    且话说清等多久、24h 去重还在（去重防「学生被重复催」，限流防「老师连点
    把系统打爆」—— 两件事）；限流放在「确实有活可干」之后（空结果连点不计数）
  · Redis 不可用时放行不瘫痪（限流是保护，不是业务前提）

二、学生微信登录也写 sys_login_log（F-31 —— 此前只有 PC 账号密码登录留痕，
   按 §13.4 查「学生登录记录」永远为空，合规缺口）
  · 新增 WechatLoginLogger：小程序登录（MpLoginService）与 H5 授权回调/
    打桩登录（MpH5AuthController）三条路径都写
  · login_type=2 与 DDL 注释对齐（1 PC 2 小程序 3 开放接口）；H5 与小程序
    共用 2（DDL 只定义到 3，不造新值），要区分看 userAgent —— 字段里本来就带着
  · 写失败不影响登录（日志表满了不能没人能登录）；不记 code/openid

验证：e2e-m5-urge → 42/42（新增「连点第 11 次被限流」断言，先清计数保证确定性）
      e2e-m3-h5-auth → 24/24（新增「两次 stub-login 各留一条 login_type=2」断言，
      清理时连登录日志一起清）

2026-09-30 12:38:48 +08:00

lovife

30c3714d35

test(scripts): 36 个 E2E 与 6 个机械校验工具（1548 条断言）+ 一键交付自检

新增：check-api-parity（契约 121 接口 ↔ 控制器，自带「必须恰好 121」自检）、
check-entity-columns（基类要求的列 vs 迁移建表列，F-35 那个坑踩了四次之后上的工具）、
check-manual（手册引用的错误码与提示文案对得上代码）、check-test-profile（test profile 真起一次）、
e2e-prodguard、load-test（四场景、按端点分别统计）、verify-all（一条命令跑完交付自检）、
dev-seed-audit（界面验收用的演示数据），以及 M1~M9 各轮 E2E。

压测抓到一个真缺陷并修掉（F-92）：门禁 IP 限流原来计「所有请求」，于是一个班连同一个
WiFi 时 60 个不同学生同时核验只过了 20 个 → 改为只计失败 + 单独的成功上限，20/60 → 60/60。

度量工具的偏差会伪装成产品缺陷（F-60/F-77/F-97），所以每个脚本都断言「动作自己的结论字段」
（submitted / created / canExport），而不是 HTTP 200 + code 0。

验证：verify-all.py --quick 5/5；--with-e2e 见 docs/09 §8。

2026-09-30 09:02:57 +08:00

2 Commits