文件关联表的核心目标是解耦附件与业务数据，支持灵活查询、安全删除和权限控制；应建独立file_attachments表，含id、file_name、file_path、file_size、mime_type、ref_table、ref_id、created_at、created_by、is_deleted等字段，并避免直接存路径或用JSON硬塞附件。
文件关联表的核心目标是让附件和业务数据解耦，同时支持灵活查询、安全删除和权限控制。不建议把文件路径直接存进业务表，也不推荐用 JSON 字段硬塞多个附件——这两者后期都难维护。
关联表结构设计（关键字段）
建一张独立的 file_attachments 表，与业务表通过外键或业务标识松耦合：
- id：主键（BIGINT AUTO_INCREMENT）
- file_name：原始文件名（VARCHAR(255)，保留用户上传时的名字）
- file_path：存储路径（VARCHAR(500)，如 /uploads/order/2024/11/abc123.jpg）
- file_size：字节数（BIGINT，方便统计和校验）
- mime_type：MIME 类型（VARCHAR(100)，如 image/jpeg，用于前端渲染或下载头设置）
- ref_table 和 ref_id：指向业务表名 + 主键值（例如 "orders" + 1024），支持多表复用
- created_at、created_by：记录谁在什么时候传的
- is_deleted：软删除标记（TINYINT(1)，默认 0；物理删除前先置 1，配合定时清理）
避免常见陷阱的实践建议
很多团队踩过坑，这里列几个高频问题和对策：
- 不要用 UUID 或时间戳当文件名——容易冲突或泄露上传时间；推荐用 随机字符串 + 原始扩展名（如 x9f3k2m8.pdf）
- ref_table/ref_id 方案比“每个业务表加 attachment_id 字段”更灵活，但要注意 SQL 查询时 JOIN 性能；高频关联场景可加联合索引：(ref_table, ref_id, is_deleted)
- 上传前校验 mime_type 和后缀是否匹配（防止伪造 .jpg 实际是 .php），后端不要只信前端传来的 type
- 删除业务记录时，别直接删文件——先查出对应附件，标记 is_deleted=1，再异步清理磁盘+OSS
配合存储方案选型
文件实际存在哪，会影响表字段和流程：
- 本地存储：file_path 是相对或绝对路径，注意 Web 服务有无读取权限；上线后建议统一挂载到独立目录，避免混在代码里
- 对象存储（如阿里云 OSS、腾讯 COS）：file_path 可存完整 URL 或内部 key，额外加字段 storage_type（local / oss / cos）便于扩展
- 如果用 CDN，file_path 存 CDN 域名后的路径即可，回源逻辑由存储层处理
基础查询与管理示例
查某订单的所有附件：
SELECT * FROM file_attachments WHERE ref_table = 'orders' AND ref_id = 1024 AND is_deleted = 0;
批量清理已标记删除且超过 7 天的文件（供后台任务用）：
DELETE FROM file_attachments WHERE is_deleted = 1 AND created_at < NOW() - INTERVAL 7 DAY LIMIT 1000;
这类操作建议加事务或幂等控制，避免误删。
