 toor
|
9241c5dcd1
|
fix: 补 panic 兜底，防止将来任何内部错误导致整进程消失
上一提交修了并发 map 写的问题（fatal error，不可 recover）。
这次给引擎加一层普通 panic 的兜底：
- safeRunTask：画廊级别，panic 时把该画廊标记失败 + 记日志
- safeDownloadPage：页级别，一页出错不带走整个 worker
- 恢复代码本身再包一层 recover —— 万一 panic 根因就是 store 出问题，
恢复逻辑不该二次崩溃逃逸出去
这不能替代修 bug（runtime fatal error 依然拦不住），
但能保证「将来再出别的内部错误」时用户能看到日志，
而不是应用无声消失、已下载的文件也白搭。
TestSafeRunTaskRecoversPanic 验证 recover 生效
（该测试在写第一版时还真抓出了恢复代码的二次 panic 隐患）。
|
2026-10-09 08:41:42 +08:00 |
|
|
toor
|
27ca6e08a0
|
fix: 修复大画廊下载时进程静默闪退（fatal error: concurrent map write）
现象：点「开始下载」后，单个画廊图片较多时整个程序无报错直接退出。
只在图片多的画廊上偶发。
根因：pageState.snapshotLocked 用浅拷贝把 Task 交给 UI：
t := *s.task // Pages map 仍是同一块内存
快照被 EventsEmit 做 JSON 序列化时，其他页 worker 正在写同一个 map，
撞上就抛 Go runtime 的致命错误：
fatal error: concurrent map iteration and map write
这是 runtime 级 fatal error，不可 recover，直接杀进程 —— 所以没有任何
报错提示。图片越多、页并发越高，并发写窗口越长，越容易触发。
同一问题还有第二处：Store.UpsertTask 存的是原值（含活的 map），
而 Flush() 会在后台 json.Marshal 整个 state，同样会撞上。
修复：
- snapshotLocked 深拷贝 Pages map 与 FailedList slice
- UpsertTask 存前先 clone()，让 store 完全拥有自己的数据
- 另加一个兜底 recover，防止将来再有 panic 直接杀掉进程
测试：
- TestSnapshotDoesNotSharePagesMap：验证快照隔离（修复前失败）
- TestSnapshotRaceWindowClosed：持续写原 task + 持续序列化快照，
精准复现崩溃窗口 —— 实测修复前 fatal error 崩进程，修复后通过
- 大画廊压测：200 页 × 页并发 20，以及 5 画廊 × 60 页 × 并发 16
测试从 62 增至 67。
|
2026-10-09 08:39:27 +08:00 |
|
|
toor
|
0447875b6d
|
feat: 双层并发 + 全局限流 + 整轮扫尾 + 画廊目录清单
原实现只能「多画廊并行，每个画廊串行下」，单张大画廊下得很慢。
按用户多年使用习惯（5 画廊 × 每画廊 8 张）改造为双层并发。
- 双层并发：画廊并发(默认5) × 页并发(默认8) = 最多 40 张同时下载，
两个值都在设置面板可调（1-20）。页级 worker 池 + mutex 保护计数。
- 全局限流：对齐参考实现的 nextRequestTime 算法，限所有请求
（含 /s/ 解析与图片本体），默认 0 秒关闭。
- 整轮扫尾：跑完后自动重扫失败页 1 轮（同样走完整 4 次退避重试），
仍失败则停下并标记 partial，换线路后手动点开始即可续传。
- 画廊目录清单 .ehdl.json：记录 gid/token/总页数/已完成页，
即使 state.json 丢失也能算出「应该多少张、还差多少张」。
顺带修复：
- Start() 双重加锁导致死锁（引擎完全无法启动）
- clampInt 越界时返回默认值而非边界值（设 30 会静默变 8）
- 直链正则写死 hath.network，CDN 换域名会全军覆没 -> 加图片 URL 兜底
- ReconcileTask 会误报「有改动」
测试从 37 增至 62，其中并发/限流/扫尾用 httptest 模拟 EH 实测：
- 页并发峰值 = 8、画廊并发峰值 = 5（完全生效）
- 12 次请求限流 80ms 实测 966ms（期望 880ms）
- 断点续传 4 张已存在时只发 5 次请求
|
2026-10-09 00:11:38 +08:00 |
|
|
toor
|
beb1dac980
|
chore: 参考脚本移入项目内 reference/ 并排除出版本库
第三方脚本（E-Hentai Downloader，作者 864907600cc）留在本地供查阅，
但不入库：避免撑大仓库、避免分发时夹带他人作品。
新增 reference/README.md 记录来源与用途，提交进库以便后人了解。
2026 版协议结论已完整落在 internal/eh/eh.go 与 README，脚本仅作 EH 改版时的对照。
|
2026-10-08 23:32:36 +08:00 |
|
|
toor
|
0f927147cd
|
feat: EH Downloader 用 Go + Wails v2 重写
原 Electron 版在这台 Windows 机器上无法启动（0x80000003 崩在 V8 初始化），
整个业务逻辑用 Go 重写，前端界面与协议结论完全保留。
- internal/eh: 协议核心，画廊页分页 -> /s/ -> hath 直链 -> 下载
- internal/core: 并发引擎 / 状态存储 / 目录模板 / 油猴桥口
- app.go: Wails 绑定层，替代 Electron IPC
- frontend/js/api.js: 适配层，renderer.js 一行未改
- 37 个测试，含 httptest 模拟 EH 的端到端链路验证
相比 Electron 版：90MB -> 12.4MB，180MB 内存 -> 27MB，构建 90s -> 2s。
顺带修掉原版代理探测的 bug（永远返回第一个端口，从不等连接结果）。
|
2026-10-08 23:28:16 +08:00 |
|