yml/dygou_go
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
105 Commits 1 Branch 0 Tags
bc366fd6b961f383708e19153e2527be83d16487
Commit Graph
76 Commits
Author SHA1 Message Date
yml2213 bc366fd6b9 feat(proxy): 支持多实例独立代理与短效API动态提取 
- 实例配置独立：支持为每个实例单独配置 http/https/socks5 代理，避免单机多开挤兑触发斗鱼出口 IP 限流
- 动态 API 提取：原生支持星空代理等平台的 API 提取（兼容 JSON/文本格式），提供前端一键提取填入与连通性/延迟测速
- 定时前自动拉取：针对 3 分钟短效代理，支持在开抢前 15 秒自动提取并绑定最新 IP，并在预热前完成热连接与时间复校
- 修复复校竞态：将 resyncBeforeTrigger 从 3s 提升至 8s，确保三轮采样在开抢前顺利落盘，消除时钟漂移
- 验证方式：通过 go test ./... 全量测试与前端 vue-tsc/vite 编译，实测通过星空代理 API 解析测试用例
 2026-10-24 19:26:16 +08:00
yml2213 288109de2f 按 10-23 三机抢购日志复盘修正重试节奏与状态口径，发布0.3.8 
10-23 三台机器 13 个实例抢同一次 18:00 的精英手册，把当天日志翻完发现
四个问题都指向"请求发得太猛、发得太早、结论分得太粗"：

- 被限流的账号仍按 100ms 节奏猛打。单实例锁单 950~1650 次（约 20 QPS）时
  18~24 个账号被"您点击太快"，而锁单仅 148 次的实例 30 个账号一次全中——
  可见"点击太快/活动火爆"是账号级封禁，继续打只会加深封禁。
- 定时器提前约 100ms 触发，想用这点提前量抵消 RTT，结果 148 次请求
  被明确拒绝："不在时间范围内 不能兑换"。它们全部落在斗鱼估算时间
  -0.026s ~ +0.172s，也就是活动还没开闸就冲进去了。
- 积分基线写盘用 os.Rename 覆盖旧文件，Windows 上会报 Access is denied，
  三机日志里出现 281 次"积分基线写入失败"，基线没落盘导致 pc-1 四个实例
  0 条核对记录，且基线为 0 时会误报"积分未见减少"。
- "已达本次活动兑换上限"被记成账号级终止失败。这其实是"该账号在本次活动
  里已经换到过了"，10-23 日志里这些账号紧接着就报了"积分已扣减，兑换确认"。

- 限流改为单账号阶梯降频：新增 throttleBackoff，第 1 次等 1~2s、第 2 次
  2~3s、第 3 次 3~4s……上限 5s，区间内随机取值避免同步醒来。throttleStreak
  独立计数，非限流的失败会把它归零——只有"连续被限流"才越等越久。
  每个账号跑在自己的 goroutine 里，降频只压它自己的下一次尝试，
  不占用并发额度、不影响其它账号的节奏。
- 触发时刻改为精确命中：dynamicAdvance 返回 0，不再提前。另加兜底守卫——
  服务端回"不在时间范围内"时该次尝试不计失败、不消耗 attempts/failStreak、
  不触发降频，用 50~150ms 快速重试直到活动真正开始。结果集里的
  "失败|不在时间范围内…"同步改写成"等待活动开始"，避免界面闪红。
- 积分基线改异步写盘：flushCh 队列 + 后台协程串行写，抢购收尾不再等写盘；
  新增 Flush 供需要确定落盘的场合。另按 build tag 分平台解决 Windows
  os.Rename 不能覆盖已有文件的问题（replace_file_unix/windows.go）。
- "已达兑换上限"单列：新增 outcomeLimitReached，结果集写"已抢到|"前缀，
  汇总行加"已达兑换上限=N"，既不计入失败也不混进"账号终止"。
- 账号不做全局去重：同一账号可以买多个皮肤，不同实例也可以抢不同皮肤。
- 新增测试 throttle_backoff_test.go（12 个用例）：降频阶梯递增、单账号级
  隔离、非限流失败重置阶梯、兑换上限不计失败且立即收手、精确命中不提前、
  活动未开始不触发降频且不记失败、Flush 同步落盘。
- 三个原有测试因降频语义变化需要调整时间尺度：新增 speedUpThrottleBackoff
  只压缩阶梯的时间尺度，不改变阶梯结构。
 2026-10-24 12:27:21 +08:00
yml2213 ac6ba0d98c 抢购控制台支持查看精英手册兑换记录，发布0.3.7 
此前只有和平小店能在控制台查兑换记录，精英/电竞手册只能去别的页面或客户端看。
现在账号作战表直接带上"兑换记录"列：查询一次就能看到每个账号兑换了什么、什么时候、
花多少积分，点"记录"看该账号全部明细。

- 新增 QueryExchangeRecords 批量查询（手册类活动）：复用既有的并发 lookupExchangeRecords，
  记录不做任何过滤（"看我的兑换记录"不该藏东西），记录自带商品名与积分
- 商品筛选为可选项：不选=看全部记录；选了则额外标记该账号是否兑换过它（已兑换/未兑换）
- 手册的商品筛选用本地状态，不写回全局商品选择——免得只是想看记录却把抢购目标改掉；
  和平小店沿用原来的全局商品选择
- 账号表"兑换记录"列对所有活动可见；手册侧展示条数与最近一条（商品名 + 时间），
  小店的"已兑换/未兑换 + 订单状态"保持原样
- 每行"记录"弹窗：若已批量查询过就直接复用结果不再打接口；否则手册走 VerifyExchange，
  小店走原有订单查询。弹窗表格按活动切换列（手册：商品/数量/兑换时间/积分/昵称）
- 聚合逻辑抽成纯函数 buildExchangeRecordsResult 并补测试
  （记录不过滤、命中按商品统计、空 Cookie 与查询失败分开计数、未选商品不做命中判断）
 2026-10-03 20:13:07 +08:00
yml2213 75eb0e8ce2 核对到的积分余额同步刷新主界面积分列，发布0.3.6 
后端在"导入账号/手动查询/抢购后核对"时都会写入积分基线，但界面一直没有读它：
积分列的 scoreMap 只由"查询积分"按钮填充，所以自动核对完余额后主界面不动，
用户必须再点一次"查询积分"才看到新余额。

- 新增 GetScoreBaselines 绑定：一次性返回各账号最近一次已记录的积分余额
  （Scheduler.ScoreBaselines → ScoreBaselineStore.Snapshot），界面直接读取，
  不必再为每个账号单独发请求
- 前端 useAccounts 新增 syncScoresFromBackend：把后端基线写入 scoreMap 与
  localStorage（与手动查询同一份状态）；导入场景下会短暂轮询等待后端异步查询写完
- 抢购状态回到 idle 时自动同步一次（对应抢购结束后的核对结果）
- 导入账号成功后按导入的账号名同步一次
- 新增断言：核对后 ScoreBaselines 返回最新余额
 2026-10-03 20:06:03 +08:00
yml2213 5da35ab65e 抢购后自动核对积分余额（基线在导入账号时获取），发布0.3.5 
兑换成功会扣积分，所以"余额确实少了多少"是一个独立于接口返回的确认证据——
2026-09-30 出现过订单实际已支付、程序却报成失败的情况，只看接口返回不够。

基线的获取时机刻意放在抢购链路之外：轮次/预热期间任何额外请求都会挤占锁单，
账号越多越明显。基线只在三个时机更新：
- 导入账号后自动查一次（后台执行，不阻塞导入返回）
- 用户手动点"查询积分"时
- 每次抢购核对之后把最新余额存回，下一次抢购的基线就是上一次的终值，差值才准
账号被编辑（改名/换 Cookie）时清掉旧基线，删除账号时一并清理。

- 新增 ScoreBaselineStore（scores.json，与账号库同目录，原子写盘）：
  记录每个账号上次已知的积分余额与时间；账号库路径为空时退化为纯内存，不写工作目录
- 核对输出示例：
  "积分已扣减，兑换确认: 账号=a 抢购前=1000 抢购后=800 扣减=200"
  并把"|积分-200"附到结果集，账号表里也能直接看到确认信息
- 没有基线时只记录余额并提示"下次抢购即可比对"，不会误报"未扣分"；
  积分接口失败只记警告，不改变"抢到"这个结论
- 抢购进行中调用导入不会去查询积分（避免与锁单抢连接），提示稍后手动查询
- 预热日志措辞修正："开始预热: N 个请求" → "N 个账号"（每账号实际不止一个请求）
- 新增测试：TestVerifyRunResultsConfirmsScoreDeduction、TestVerifyRunResultsWithoutBaseline、
  TestVerifyRunResultsIgnoresScoreFailure、TestScoreBaselineStorePersists、
  TestFetchScoreBaselinesRecordsValues
 2026-10-03 19:57:13 +08:00
yml2213 67f0b28ab6 按"锁单优先、支付从容"放宽支付时序，发布0.3.4 
设计前提（此前被我自己违反过一次）：锁单一旦成功就占住了库存（斗鱼锁单有效期 300 秒），
支付晚几秒没有任何损失，所以支付环节不该抢时间——斗鱼对"锁单→支付"有最短间隔，
打得太密只会收到"您点击太快"、把账号往风控上推。

- 首次支付等待 2.3-3.0s → 2.5-3.5s，给实测阈值 (1.68s, 2.1s] 留更足余量
- 支付退避阶梯全面放缓（不再追求快重试）：
  在途 300ms→1s 改为 500ms→2s；频控 800ms→2s 改为 1.5s→4s；其它 400ms→1.2s 改为 800ms→2.5s
- 单笔支付总预算 120s → 180s：仍远小于锁单 300 秒有效期，但足够扛住两次 10-03 级别的
  服务端堵塞，同时把请求数减半
- 把这条设计前提写进 payLockedOrder 与支付阶梯的注释，避免以后又被当成"浪费"优化掉
- 新增 TestFirstPayDelayStaysAboveServerMinimum：断言首次支付等待不低于实测阈值 2 秒、
  等待区间合法、总预算大于首次等待上限
- 设置页补充说明：锁单优先、支付晚几秒无损失，以及支付重试上限改为 180 秒

确认既有架构已经满足该前提（无需改动）：每账号独立循环，一个账号在支付时其它账号继续锁单；
并发额度只按单次请求发放，支付等待期间不占额度；75 秒窗口只限制发起新锁单，不限制支付；
已锁单的账号不再发起新锁单以免重复下单。
 2026-10-03 19:43:56 +08:00
yml2213 87f9c7994d 按实测修正锁单后支付间隔并在日志表头补充版本号，发布0.3.3 
- 锁单后首次支付的等待从 0.3-0.7 秒改回 2.3-3.0 秒。斗鱼对"锁单→支付"存在最短间隔：
  2026-10-03 19:38 的模拟里，+0.50s/+0.60s/+1.37s/+1.68s 发起的支付一律被
  "您点击太快，请稍等再试"拒绝，而 +2.56s/+3.30s 发起的都成功；19:20 那次在
  +2.1s~+3.9s 发起的 6 笔全部一次通过，阈值落在 (1.68s, 2.1s] 之间。
  0.3.1 把等待压到 0.3-0.7 秒踩进该区间，6 个号各白挨两次拒绝，反而多花 2.7 秒、
  多打 12 个请求——上一版"2-4 秒纯属浪费"的判断是错的，那段等待本就是躲这条服务端规则
- 日志文件表头补充版本号与构建时间：此前无法从日志判断用户跑的是哪个包
- 新增测试断言表头包含版本号
 2026-10-03 19:42:00 +08:00
yml2213 dce9ce2a5a 优化日志系统：网络请求降噪并按接口聚合，补齐双时间说明与实例标识，发布0.3.2 
- 逐条网络日志（请求完成 / 接口返回异常 / 响应刷新CSRF已同步）从 info/warn 降为 debug：
  实测一次 6 账号的模拟抢购里 233 条日志有 174 条（74%）属于这类；真实抢购会产生几千条，
  把界面仅 800 条的内存日志冲掉，反而看不到关键信息。HTTP/解析/传输层错误仍为 error 级
- 新增按接口聚合的网络统计，抢购任务结束时输出一行，替代逐条刷屏：
  "接口统计: 锁定兑换商品 ×341 失败341 平均=95ms 最慢=312ms 最后错误=活动火爆，请稍后再试"
- 日志文件开头新增表头：实例名、数据目录、双时间格式说明（本地时间 + D 斗鱼估算时间）、
  并说明"校准完成前偏移为 0，只显示本地时间"。双时间一直存在却没有任何地方解释过，
  多实例日志复制或汇总后也分不清来源
- 界面日志面板：显示日志级别并按级别着色（此前级别只存在于 CSS class，复制出去就丢）；
  新增"复制"按钮，按与日志文件一致的单行格式导出（此前直接复制会变成 5 行一条、
  1204 行里其实只有 233 条日志）
- 设置页"日志显示等级"补充说明：Info 起只显示关键日志，需要逐请求细节时切到 Debug
- 新增测试：TestRequestStatsAggregatesByLabel、TestLogFileHeaderDocumentsFormat、
  TestRunNowLogsAggregateInsteadOfPerRequest（断言必须有聚合行、且不得出现逐条请求日志）
 2026-10-03 19:33:14 +08:00
yml2213 43270e04a6 收紧重试退避并把首发请求改成立即发出，发布0.3.1 
- 退避上限从 5 秒压到 1.5 秒（含抖动最长约 1.9 秒），连续失败放大倍数 8→4，抖动 50%→25%：
  2026-10-03 实测库存只活了约 1.1 秒（PC2 四个实例 18:00:00.171~18:00:01.101 一直能锁到
  同一个礼包），而 PC1 默认实例的 31 个号在 18:00:00.225 失败后一直睡到 18:01:09.379，
  唯一有货的那段窗口被退避吃掉；超过 2 秒的等待都可能正好错过库存回流
- 首发请求不再随机等 150-700 毫秒，改为"第 0 个账号立即发出 + 其余按 8ms 步长错开"，
  整批铺开不超过 300 毫秒（账号再多也不会拖长）。定时器本来就提前约 100ms 触发以补偿 RTT，
  再抖几百毫秒等于把这个提前量整个抵消，请求实际落到 t+150ms~t+650ms
- 锁单成功到首次支付的等待从 2-4 秒压到 300-700 毫秒：这段纯属把关键路径上的时间白送出去，
  "订单操作进行中"现在按"已受理、结果未定"快重试，不需要靠等待规避
- 支付退避上限同步收紧：频控 3s→2s，其它 2s→1.2s（在途仍为 300ms→1s）
- 新增 TestRetryDelayNeverBacksOffLong：遍历 75 秒 × 40 次连续失败，断言任何一次退避都
  小于 2 秒，并覆盖"重试间隔策略被配到 5000ms"的极端配置
- 新增 TestFirstWaveStartsImmediately：单账号步长必须为 0、位次从 0 递增、
  2/34/100/500/2000 个账号下步长 ≤8ms 且整批铺开 ≤300ms
- 设置页文案同步：退避"任何一次等待都不超过约 2 秒"、首发错开说明
 2026-10-03 19:21:26 +08:00
yml2213 46c06180a5 重构锁单支付重试内核并修复多实例启动，发布0.3.0 
- 抢购内核改为"每账号独立重试循环"，移除轮次屏障：旧实现在 3 个中签账号卡住
  60 秒支付退避时，另外 31 个账号空转 39 秒，还出现过"某一轮只跑 1 个账号、其余整轮没被尝试"
- 锁单退避改为读取配置的"重试间隔策略"（同一账号连续失败成倍放大，封顶 5 秒），
  删掉硬编码 30 秒退避与"只重试一次"
- 锁单失败不再提前停止：限流（活动火爆/网络繁忙）继续重试；售罄也继续降频探测
  （别人锁单后支付失败或锁单过期，库存会回流），只在窗口结束时按售罄/限流/普通失败分类上报
- 支付重试按斗鱼错误码决策：1644430001/1644400002/1644400014 视为"订单已受理、结果未定"
  并快重试（300ms 起），取代按文案把"订单操作进行中"误判成频控的 60 秒退避；
  不再设次数上限，只受 120 秒预算与锁单过期约束，超出预算如实报"支付结果未知"
- 已锁订单在 75 秒窗口结束后仍会支付完，不再受窗口约束
- 多实例：为每个实例分配独占的 WebView2 用户数据目录。Wails 默认所有实例共用
  %APPDATA%\<可执行文件名>，而一个数据目录只能有一个浏览器进程，导致偶发开不出新实例、
  必须全部关掉重开；实例占位因此提前到 wails.Run 之前完成
- 多实例：占位失败不再静默退回默认目录（会让两个进程共享 accounts.txt/config.json、
  同秒启动还会写同一个日志文件），改为进程唯一的临时实例目录并记录降级原因
- 多实例：单个槽位锁被瞬时占用（杀软/索引器）时短暂重试，仍失败则继续试下一个槽位
  而不是整个分配失败；日志文件改为独占创建，同秒启动自动追加 -2/-3 后缀
- 新增 %LOCALAPPDATA%\douyu-go\startup.log，记录每次启动与失败原因，
  便于排查"窗口起不来"这类连应用日志都不会生成的问题
- 修复预热缓存日志每个账号打两遍、"账号尝试"计数误导（改为真实锁单/支付/直接兑换次数）
- 修复前端把含"成功"字样的失败文案显示成抢到（改为只认"成功|"前缀）
- 修复 jitterDuration 在基准小于 10ms 时 rand.Int63n(0) 会 panic 的隐患
- 设置页文案与作用域同步：重试间隔策略明确作用于锁单重试、"尝试包数"明确仅用于和平小店
 2026-10-03 19:09:19 +08:00
yml2213 1f76c12b48 精英手册改为锁单支付并发布0.2.2 
- 精英手册兑换改为 createExchangeOrder 锁单后 payExchangeOrder 支付，不再查询商品状态与预兑
- 电竞手册保留直接兑换，标准模式重新取鉴权，激进模式复用鉴权
- csrfToken 优先复用 Cookie，校验失败自动刷新后重试一次
- 锁单支付按频控/通用退避表重试，临近过期不再重试
- 定时复校发现抢购已开始则不再改写触发时刻
- 升级 wails 至 v2.15.0
 2026-09-30 20:35:44 +08:00
yml2213 911f967463 优化账号商品选择并发布0.2.1 2026-08-09 20:04:55 +08:00
yml2213 266f4a3da1 修复库存监控提前停止并发布0.2.0 2026-08-09 19:37:30 +08:00
yml2213 02d38d9ede 支持按账号商品监控库存抢购 2026-08-09 18:46:39 +08:00
yml2213 a9ad969b64 支持多开实例隔离并默认打开小店 2026-08-09 17:25:18 +08:00
yml2213 fde6b00780 优化小店报告订单状态展示 2026-08-09 16:09:50 +08:00
yml2213 0c55da1e97 新增小店抢购报告导出并优化停止条件 2026-08-09 16:06:46 +08:00
yml2213 2e9847e15d 抢购完成后自动刷新小店资产 2026-08-09 15:08:10 +08:00
yml2213 754e3f1ca8 优化和平小店抢购重试策略 2026-08-09 14:48:20 +08:00
yml2213 87cb1dc3f0 新增库存监控并优化开发日志 2026-08-09 14:06:55 +08:00
yml2213 8cf29598a5 升级版本并改用内部账号存储 2026-08-09 13:04:54 +08:00
yml2213 1cd94c0179 优化和平小店兑换记录查询 2026-08-09 12:54:37 +08:00
yml2213 8919d020c5 修复和平小店商品图片和库存展示 2026-08-09 12:38:08 +08:00
yml2213 1b697ced09 合并远程main并保留和平小店功能 2026-08-09 10:52:56 +08:00
yml2213 cd1c3db691 停止重复兑换已拥有道具账号 2026-08-09 10:35:30 +08:00
yml2213 c41fd48b1c fix: preserve xiaodian ios platform in asset queries 2026-08-09 10:10:49 +08:00
yml2213 feb72196c1 优化和平小店碎片兑换链路 2026-08-09 10:07:36 +08:00
yml2213 c6f16dfbee 增强和平小店账号管理 2026-08-09 09:18:41 +08:00
yml2213 dde2b43d82 feat: improve xiaodian seckill flow 2026-08-08 23:04:40 +08:00
yml2213 16972b41cd 升级版本并完善双平台打包 2026-08-08 19:52:00 +08:00
yml2213 c84940a5dc 新增和平小店兑换记录查询 2026-08-08 19:44:39 +08:00
yml2213 57344c7874 完善CK管理增删改导入 2026-08-08 19:30:23 +08:00
yml2213 68bdd6b42c 提高和平小店固定抢购次数上限 2026-08-08 18:57:09 +08:00
yml2213 a4fed8befb 增加和平小店关键词固定抢购 2026-08-08 18:40:53 +08:00
yml2213 51e91b0483 增加和平小店商品分类展示 2026-08-08 18:29:31 +08:00
yml2213 06ad1498da 优化和平小店商品列表界面 2026-08-08 18:01:10 +08:00
yml2213 395096e229 查询扭蛋碎片+点券 2026-08-08 17:50:00 +08:00
yml2213 379a9d58d3 小店商品列表shujuok 2026-08-08 17:40:16 +08:00
yml2213 22dc50196f 增加版本号 2026-07-29 14:49:37 +08:00
yml2213 c052a589d1 完善电竞手册鉴权与诊断日志 2026-07-29 14:24:26 +08:00
yml2213 f64838f8db 优化一些功能 2026-07-29 14:02:56 +08:00
yml2213 2c88edb741 重构: 应用代码移入 internal/app 包，根目录只留入口 
根目录原 7 个 app*.go 平铺，现收进 internal/app/ 子包：
- package main → package app
- NewApp → New（导出）
- startup/shutdown → Startup/Shutdown（导出，供 main.go 引用）
- main.go 改为薄入口，仅导入 internal/app 并装配 Wails

前端同步更新（Wails 绑定路径 go/main → go/app）：
- window.go.main.App → window.go.app.App（10 处）
- env.d.ts 类型声明路径 wailsjs/go/main/App → wailsjs/go/app/App

根目录 Go 文件从 7 个减至 1 个（main.go），元文件更清晰
 2026-07-29 13:27:08 +08:00
yml2213 5631f579ea 重构: 按领域拆分大文件，清理死代码和空目录 
app.go (768行) 拆分为 6 个文件:
- app.go: App struct/辅助方法/NewApp/startup/shutdown/GetVersion
- app_products.go: 商品加载/账号查询
- app_seckill.go: 抢购控制/日志/时间
- app_verify.go: 积分查询/兑换记录复验
- app_export.go: 账号导出/整理
- app_activity.go: 活动切换/配置保存

scheduler.go (1141行) 拆分为 4 个文件:
- scheduler.go: struct/常量/设置/RunNow主循环/executeRound/辅助函数
- attempt.go: runAttempt/runAttemptFast/激进模式缓存
- warmup.go: 预热管理/warmupAttempts
- schedule_timer.go: 定时抢购/时间校准/定时器管理

其他清理:
- CollectFontCandidates 从 config 包移到 image 包（职责归属）
- 删除 logger 死代码: ParseLogLine/ParseLogMeta/DetectLogLevel/
  IsLogLevel/LogMeta/LogDebug/cutBracket 等反解析函数及对应测试
  （日志结构化后不再有生产调用方）
- 删除 static/ 空目录残留
 2026-07-29 13:19:43 +08:00
yml2213 b72a58fd57 重构: 日志系统结构化，消除字符串反解析 
旧链路：LogEvent→log.Print→logFileWriter→MemoryLogStore.Write
再用 ParseLogLine 字符串切割把分类/级别/账号反解析回来，格式一调就崩。

新链路：LogEvent 直构 LogEntry（Time/Level/Category/Account 直接填值），
经 sink 分发到内存(同步)/文件(异步)/终端。Message 仍用 formatLogLine
渲染保持文件文本格式与前端清理逻辑兼容。

- MemoryLogStore 新增 Append(entry) 替代 Write 的字符串解析路径
- 删除 logFileWriter，新增 sink 统一管理三路输出
- 删除 log.SetOutput/log.Print 依赖
- 保留 ParseLogLine/DetectLogLevel/formatLogLine（AsyncLogWriter 丢弃
  统计与测试仍用），但 log_store 不再调用
- 新增 TestStructuredLogging 覆盖 LogEvent→sink→Append 链路与 minLevel 过滤
 2026-07-29 12:52:26 +08:00
yml2213 7c2c5a61a6 重构: 账号管理抽离、强类型返回、消除反射、删除死字段 
- 抽离账号管理为独立 AccountStore，Scheduler 只持有引用，
  职责单一化（scheduler.go 减少 ~110 行）
- Wails 绑定方法返回结构体替代 map[string]any（新增 responses.go），
  前端获得强类型，字段名保持兼容无需改前端
- ExchangeRecord 移至 types 包，消除 types↔client 循环依赖
- extractAPIStatus 用 apiResponder 接口替代 reflect 逐字段查找，
  types.APIResponse 与 ExchangeListResponse 实现 APIStatus 方法
- 删除 types.Account.Password 死字段（鉴权仅用 Cookie）
- 重新生成 Wails 绑定，前端 vue-tsc 类型检查通过
 2026-07-29 12:47:01 +08:00
yml2213 3ae9cb4a42 重构: 活动热切换并发安全 + 代码清理优化 
- 活动切换并发安全：App/Scheduler 增加 client/cfg 读写锁与快照访问，
  支持运行中热替换客户端，切换活动不再静默覆盖用户自定义 timeApiUrl
- 启动失败时写入崩溃日志文件便于事后排查
- 前端类型声明从 Wails 自动生成的绑定派生，避免手写契约漂移
- 提取 parseAccountFile 消除 ExportAccounts/OrganizeAccounts 重复解析逻辑
- 删除 utils 中未使用的 ReadJSON/WriteJSON/WriteError 及空目录 internal/app
- gofmt 统一格式化（activity/types/scheduler 字段对齐）
- 新增 logger/seckill/utils 单元测试
- 清理 git 中遗留产物（frontend/app.js、yml.txt、其他日志/）并补全 .gitignore
 2026-07-29 12:33:16 +08:00
yml2213 ed3fd5f09e fix: peacematch 兑换用 multipart/form-data（与抓包一致） 
根据实际兑换抓包修正：
- Content-Type 从 urlencoded 改回 multipart/form-data（浏览器实际用 multipart）
- postMultipart 支持组合 token csrf\x00ctn，自动拆分并合并 cvl_csrf_token+acf_ccn 到 Cookie
- 移除不再需要的 postForm 方法和 net/url 导入
- 验证：表单字段(manualID/commodityID/num/rid/ctn)与抓包完全一致，
  storedetail 确认无 preExchange 字段（时间校准修复正确）

抓包来源：/Users/yml/Desktop/抓包/douyu/7.29/电竞手册-兑换并查询信息与积分.har
 2026-07-29 11:08:49 +08:00
yml2213 599f9d71f0 fix: 电竞手册用 ctn(acf_ccn) 鉴权替代 csrfToken 
peacematch 与 peace 的兑换接口鉴权机制完全不同：
- peace: 表单发 csrfToken 字段，multipart 格式
- peacematch: 表单发 ctn 字段(值=acf_ccn)，urlencoded 格式，
  cvl_csrf_token 只放 Cookie，不需要 batchExchangeLimit/preExchange

改动：
- Activity 加 UseCTN/CTNURL 字段
- GenerateCSRF 对 UseCTN 活动额外 FetchCTN 获取 acf_ccn，组合返回
- 新增 postForm(urlencoded) 方法用于 peacematch 兑换
- Exchange 按 UseCTN 分流：peacematch 发 ctn 字段，peace 发 csrfToken
- BatchExchangeLimit/PreExchange 对 UseCTN 活动跳过(返回默认值)
- 参考 /Users/yml/codes/douyu_login_py 中 Python 实现
 2026-07-29 11:05:46 +08:00
yml2213 8e52e12005 fix: 时间校准接口全局复用旧 peace/storedetail，修正活动名称 
- 从 Activity 结构体移除 TimeAPIURL 字段，时间校准与活动无关，
  统一用 constants.DefaultTimeAPI（peace/storedetail 能稳定返回 currentTime）
- 旧活动 peace DisplayName 从"和平手册"修正为"精英手册"
- 更改项目默认端口避免冲突：Vite 5173→15173，Wails dev 34115→34215
 2026-07-29 10:48:42 +08:00
yml2213 f4d33d19c0 增加电竞手册 2026-07-29 10:36:44 +08:00