同一张连戏照片为什么会有数据本体和文件路径两份记录

一张连戏照片在 SlateX 里可能同时有两份不同性质的记录：数据库里的图像数据，以及指向应用沙盒中磁盘文件的相对路径。界面展示读取的是图像数据，删除文件时依赖的是已保存的相对路径。两者服务不同动作，因此“画面还能看到”和“磁盘上的那份文件能被精确找到并删除”不是同一件事。

图像数据回答“显示什么”，文件路径回答“删哪一个文件”；两份记录不能互相替代。

展示读图像数据，删除认相对路径

卡片、详情、引用区和比对界面都从数据库里的图像数据读取照片，只是在不同界面使用不同的缩略规格。也就是说，只要图像数据还在，界面就有自己的显示来源，并不需要先沿磁盘路径重新打开那张照片。

删除逻辑正好相反。删除素材或连戏库文件时，代码使用之前持久化的相对路径去定位磁盘文件，并且明确禁止根据当前模型字段重新猜文件名。没有一条被保存下来的精确路径时，删除逻辑不会通过名称扫描去“找一个看起来像”的文件。

这就是为什么同一张照片需要同时理解成“数据库对象”和“沙盒文件”。数据库对象可显示，不等于磁盘文件的权威位置已经记录完整；磁盘路径存在，也不表示展示端会反过来依赖它。

挂在条记录上的连戏素材使用项目、场、镜、条这一层级形成路径；挂在连戏库条目上的封面或引用素材，则按连戏库的类别与条目名形成文件名。两条路径族表达的是不同的业务归属，不应该只看文件名猜它属于哪一个对象。

这种命名也解释了为什么条目改名时文件名会变化。连戏库条目每次带图保存，都会使用当前类别与当前名称生成新的文件名，先写入新文件并成功保存记录，随后才删除旧路径指向的文件。因此改条目名不是只改数据库里的文字标签，带图保存时磁盘文件名也会随当前名称重新生成。

快速新建并关联连戏库条目时，当前代码只写封面图像数据，不写封面文件路径。近场接收进来的照片也只写图像数据，不写照片路径。于是这两类记录在界面上仍然可以有图，但删除逻辑没有一条已持久化的权威路径可用。

这里能确认的是“哪一步没有写路径”，不能继续写成“所以磁盘文件一定会累积”或“所以发生了泄漏”。那属于结果层，需要文件系统样本与实际删除测试才能下结论。

路径缺失是可定位的代码事实；磁盘最终留下什么，是另一层需要实测的结果。

数据库里保存的图像数据可以进入账号侧的数据镜像，而那条被持久化的本地文件路径指向的文件本身不在同一镜像范围里。因此不能把“数据库记录在另一台设备出现”写成“那条路径指向的沙盒文件也已经出现”。

所有这些媒体文件都位于应用自己的沙盒，而不是 App 包内的静态资源。删除应用时，沙盒中的本地文件会随应用数据一起消失。另一方面，这也不构成“云端可恢复照片”的承诺，因为本篇只说明数据库数据与本地路径的关系，不证明重新安装或换设备后的恢复结果。

视频记录主要依赖本地路径来定位文件，并且读取时有落地区回退逻辑，以应对记录中的路径仍指向文件写入时所在位置的情况。它与照片“展示直接读数据库图像数据”的路径不同，所以不能把照片的双写机制直接套到视频上。

这篇能回答的是：同一张照片为什么有图像数据与路径两份记录、谁读哪一份、改名时为什么会换文件名，以及哪些写入路径没有留下权威路径。它不能据此承诺自动去重、跨设备恢复或文件不会丢失。

因为显示端读取数据库里的图像数据，而删除端依赖持久化的相对路径。两条链路读取的是不同记录。

带图保存时不会只改文字。当前实现会按新的类别与名称生成新文件名，保存成功后再处理旧路径。

快速新建并关联连戏库条目的封面，以及近场接收的照片，当前写入链路都存在只写图像数据而不写权威路径的情况。

不能这样推断。数据库图像数据与本地沙盒文件是不同层，路径指向的本地文件不因为数据库记录存在就被证明已经出现在另一台设备上。

上海智独教育科技有限公司 — SlateX。以上数字截至 2026-09-24。