rond-with-you

Files

T

tamakyi f98d3864b8 导出：zip 用 CreateRaw 写长度/CRC，别再带 data descriptor（真机判整包损坏）

真正的病根（09-16 起每一份站点导出都被拒都是它）：Go 的 zip.Writer 默认走流式写入——本地头里
的长度与 CRC 留 0、真值挪到条目尾部的数据描述符里，并在 flag 里置 bit3。**真机的读取器只认
「本地头里就写着长度」的条目**，遇到这种包直接判成损坏，报「备份恢复失败，你的当前数据未被更改」。

铁证（直接读文件头）：
  站点 Go 写的每一份导出        本地头 flags=0x0008  csize/usize=0/0   → 全部被拒
  20260920-fixed-A-数据修复    本地头 flags=0x0000  有长度             → 真机接受（Python 重打包）
  真机自己的包                 本地头 flags=0x0800  有长度             → 正常（只有 UTF-8 位）

这也解释了之前为什么全都修错了方向：09-20 那次「修悬空引用后就能导入」其实是 Python 重打包顺手把
zip 写法修对了；而 09-29 一整天修的内容问题（活动颜色为 NULL、交通方式重名）都不是拦路虎。

修复：zipBackup 改用 zw.CreateRaw，先把三个文件读进内存算出 CRC32 与长度写进本地头，
不再用会置 bit3 的 zw.CreateHeader。

用例：TestZipBackupWritesNoDataDescriptor —— 直接读第 0 个条目的**本地头**，断言 bit3 为 0、
压缩/原始长度非 0、CRC 正确（变异验证：改回 CreateHeader → 立刻变红，且精确复现 0x0008 + 长度 0）。
真实数据验证：修复后新导出的本地头 flags=0x0000、长度正确。

全量验收 296 PASS / 0 FAIL / 0 SKIP。

2026-09-29 15:04:07 +08:00

diff_test.go

合并：地点配对只留一份实现（rond.MatchPlaces），合并侧不再自己配一遍

2026-09-29 10:46:54 +08:00

diff.go

合并：地点配对只留一份实现（rond.MatchPlaces），合并侧不再自己配一遍

2026-09-29 10:46:54 +08:00

dirty_test.go

审计修复：后端（安全 / 数据一致性 / 性能）

2026-09-24 20:37:16 +08:00

export_roundtrip_test.go

first release