图片切分：除行列数外，更要约定「遍历顺序、接缝禁区与 ZIP 内文件名排序」三件事
本工具在浏览器里把单张母图按等分网格切成多块 PNG，并打包成一个 ZIP 本地下载，全程不经过服务端存图。真正容易翻车的不在「能不能切」，而在数学与流程：宽或高不能被列行整除时会出现余像素，最后一列/行会比其它块差一两个像素，脚本或拼图工具若假设「每格绝对相同」就会对不齐。PNG 无损但体积大，块数一多 ZIP 会膨胀，弱网环境解压与二次上传都要预留时间。跨场景还要统一「行优先还是列优先」编号、文件名零填充位数，以及 Instagram 主页九宫格「先发的那张会跑到网格右下角」这类读序与上传顺序的反向关系。打印与工单场景还要单独考虑出血、最小字号与引用块号是否绑定设计稿版本。把这些写进交付说明，比事后在群里争论「你那张是第几块」便宜得多。
图片切分怎么用：先对齐像素能否整除，再叠网格验刀线，最后按渠道规则排序 ZIP 内文件并演练上传
- 上传前在稿子里读出原始宽高，心算或表格验算「宽÷列、高÷行」是否整除；若有余数，决定是改画布补边、改行列数，还是接受最窄列并在下游拼图逻辑里单独处理。同时写死行优先或列优先编号与两位/三位零填充规则，避免 `10` 排在 `2` 前面的字典序事故。
- 在工具预览里打开网格叠加，检查人脸中线、主标题字重区、Logo 与二维码是否压在刀线上；对细线图标与小于 12px 的文字单独放大验收。若目标端会再压 JPEG 或套圆角蒙层，要在心里预留一圈安全区，而不是只以全尺寸设计稿为准。
- 导出 ZIP 后在本地按「最终上传顺序」重排文件夹视图走一遍 dry-run，核对数量与总像素；需要给运营同事时附带一张带编号缩略图的索引 PNG 或表格映射。商业用途另存原图哈希、行列参数与导出时间，便于以后同版替换或法务取证。
图片切分常见问题：余像素、编号顺序、无损体积与跨渠道读序
为什么有时切出来的某一列比其它列窄一像素，拼回大图时脚本对不齐，这是工具错了还是网格参数与原始尺寸不匹配？
多数是整数除法余数被摊到最后一列或最后一行导致。解决办法要么改画布尺寸让宽高都能被行列整除，要么在需求里显式允许「尾列不同宽」并在拼接代码里读真实宽高数组，而不是写死统一 `cellW`。导出前用计算器验一遍比事后改前端便宜。
ZIP 里 PNG 顺序在 Windows 与 macOS 预览里都对，但同事上传后九宫格故事线反了，该怪文件名还是怪平台展示规则？
Instagram 主页网格最新帖显示在右下角，整体叙事从屏幕右下往左上读，和文件夹排序方向常常相反。要在 brief 里画一张「第几步上传对应最终网格哪一格」的示意图，并用 `01_先上传` 这类语义前缀，而不是只依赖默认排序。
块数多、每块又是透明 PNG，ZIP 体积暴涨导致邮件发不出、网盘限速，有没有不损接缝的减负思路？
透明区域多的母图切开后每块仍带大量 alpha，体积正常会炸。可先评估是否真的需要透明底；若只是社媒发布，可在切分前合并为白底或品牌底再导出。若必须透明，尝试在源稿合并重复空白或降低超大画布像素尺寸，再切分。
同一套切片既要用于对外投放又要进内部评审工单，怎样避免「块号对得上但版本对不上」的扯皮？
块文件名里嵌入母图版本号或 Git 短哈希，例如 `hero_v3_r2_c3.png`，工单描述写「引用 hero_v3 第 2 行第 3 列」。禁止口头说「右下角那块」这种随屏幕尺寸漂移的说法。审批通过后再允许运营改文件名上架。
活动紧急，能不能不预览网格直接批量导出？历史上最容易在这种时候踩哪几个雷？
可以但不建议。最常见的雷包括：主标题被横线对半切开、二维码刚好落在四格交界、透明底在深色个人主页上融成一团，以及上传顺序错误导致整周预热叙事倒序。至少抽一张最复杂主视觉完整走一遍网格与上传演练，再批量套同样行列配置。