网站建设中图片：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a483abbc498b.html
📄
网站建设中图片：旧系统字段无法完整迁入时怎样决定保留项
结论先行：当旧系统的图片字段无法完整迁入时，保留项不应按“字段在旧库里是否存在”来决定，而应按“这个字段是否承载了页面必须呈现的信息”来决定。把每个字段映射到具体页面位置和用途，能完整对应上的保留，找不到落点的先冻结；一旦发现某个字段被前端模板、外部引用或人工流程实际依赖，这条规则就要推翻，改为优先保留并单独迁移。
先建立字段到页面位置的对照，而不是先看数据库
多角色对同一事实理解不同，通常是因为各自看到的层面不一样：开发看表结构，编辑看后台表单，设计看页面效果。把分歧转成可核对项目的做法，是拉一张对照表，每行一个旧字段，列出三列内容：它原本出现在哪个页面位置、由谁在什么流程里填写、去掉后页面会出现什么可见变化。
对照表填完后，保留项自然分成三类。第一类是有明确落点且内容不可再生的，例如图片说明文字、拍摄时间、授权备注，这类应保留。第二类是有落点但可由其他字段推导的，例如由文件路径推断出的分类，这类可以不迁，改为迁移后按规则重新生成。第三类是找不到任何落点的，先冻结而不是直接删除，因为“暂时没人说得清”和“确实没用”是两回事。
这里有一个可操作的动作：让编辑和设计各自独立填写对照表，再比对差异。差异行就是需要当面确认的分歧点，而不是靠会议上的口头描述去猜。比对结果会直接决定下一步是进入字段映射脚本，还是先补一轮页面用途梳理。
判断保留优先级时，区分“展示依赖”和“管理依赖”
图片字段的价值有两种来源，容易被混为一谈。展示依赖指页面渲染时直接读取这个字段，缺了它页面就少一块内容；管理依赖指页面不直接显示，但后台筛选、批量操作或对外接口依赖它。两者都构成保留理由，但处理方式不同。
- 展示依赖的字段，迁移时必须保证值完整，缺失会导致页面出现空白或占位图。
- 管理依赖的字段，可以先迁结构再补值，但要确认依赖它的流程在迁移期间是否暂停。
- 两者都不满足的字段，进入冻结清单，保留旧库快照即可，不占用新系统字段位。
假设一个场景：旧系统里有一个“图片来源”字段，前台从不显示，但编辑每周按它筛选出一批图片做版权核查。这个字段属于管理依赖，不能因为页面上看不见就丢掉。反过来，如果某个字段只是早期模板遗留、现在既无展示也无流程使用，把它迁过去只会让新后台的表单更长，增加填写负担。
会让上述规则失效的反例
按页面落点决定保留项，有一个明确的反例：当某个字段的值被外部系统或静态引用直接使用时，页面落点判断会给出错误结论。例如旧站的图片路径被合作方页面、邮件模板或线下物料以固定地址引用，这些引用不在你的页面模板里，但一旦路径规则变化就会断链。
这种情况下，字段本身可能在新页面里没有位置，但它承载的路径信息必须保留或以兼容方式延续。判断方法是先收集外部引用来源，而不是只看站内模板。如果无法穷举外部引用，保守做法是保留旧路径可访问，而不是立即切换到新规则。这个反例说明：保留项决策要同时覆盖站内展示和站外引用两个范围，只做前者会漏掉真实依赖。
把结论落到一次可核对的迁移动作上
完成对照表和依赖判断后，下一步动作是生成一份迁移清单，每个字段标注三件事：目标字段名、迁移方式（直接复制、规则转换、重新生成、冻结）、验证方式。验证方式要具体到可执行，例如“随机抽取若干条记录，比对迁移前后该字段在页面上的呈现是否一致”，而不是写“检查是否正常”。
这份清单的作用是把角色分歧固定下来：开发按迁移方式执行，编辑按验证方式抽查，设计确认页面呈现没有缺块。任何一方在验证中发现对不上，回到对照表修改对应行，而不是在迁移脚本里临时打补丁。这样一来，保留项的决定有据可查，后续新增字段也能沿用同一套判断路径。
如果对照表填写阶段就出现大量找不到落点的字段，说明页面用途本身还没梳理清楚，此时应先暂停迁移范围确认，把页面清单补齐再继续，否则保留项会随理解变化反复推翻。
