rosercode
15fd1a263d
fix: 兼容支付宝新版交易明细导入并修复外部交易号超长截断
支付宝新版「交易明细」导出格式的列名与旧版「交易记录明细查询」完全不同，导致导入直接报「未找到支付宝账单表头」；此外部分长订单号超过 t_transaction.external_no 的 VARCHAR(64) 长度，导入时触发数据库截断报错。本次让解析器同时兼容新旧两种格式，将 external_no 加宽至 VARCHAR(255)（含已存在库的自动迁移），并补充导入失败日志便于定位。
变更内容：
- AlipayBillParser 兼容新版「交易明细」：支持「交易时间」开头表头、新版列名映射（交易订单号/商品说明/金额等）、斜杠时间格式（yyyy/M/d H:mm[:ss]）、交易号去空白、尾部逗号空行跳过与 UTF-8 BOM 处理。
- SchemaMigrator 新增 external_no 加宽迁移：MySQL 检测当前长度不足时执行 ALTER 至 VARCHAR(255)，幂等可重复执行，SQLite 不强制长度直接跳过。
- BillImportServiceImpl 补充日志：逐行校验失败、批量插入回退、单条插入失败（含 externalNo 与根因）、重复跳过分别记录 warn/debug，便于定位失败记录。
- init.sql 与 schema-sqlite.sql 将 external_no 由 VARCHAR(64) 调整为 VARCHAR(255)，保持两库结构一致。
说明：
- 旧版「交易记录明细查询」格式的解析行为保持不变。
- 长度迁移在应用启动（DatabaseBootstrap）与切换数据库时自动执行，无需手工执行 SQL。
- 64 到 255 跨越长度前缀边界，MySQL 调整列时会重建该表，数据量小影响可忽略。
2026-09-30 15:54:11 +08:00
..
2026-09-17 13:19:59 +08:00
2026-09-17 16:47:26 +08:00
2026-09-30 15:54:11 +08:00
2026-09-30 15:54:11 +08:00