文件系统不支持自定义元数据，怎么办
Windows NTFS 和 Linux ext4 等主流文件系统原生只提供有限元数据（如修改时间、权限、所有者），
File.GetAttributes或
stat返回的字段无法容纳业务字段（如“审批状态”“来源项目ID”）。硬塞进文件名或扩展名会破坏语义、影响工具兼容性，也难检索。
可行路径只有两条：外挂数据库 + 文件路径映射，或利用文件系统已支持的扩展属性（xattr）机制。前者通用但引入额外依赖；后者轻量但跨平台支持不一。
Windows NTFS 支持Alternate Data Streams (ADS)，可用
FileStream打开
file.txt:custom_meta写入二进制数据 Linux/macOS 支持
xattr，C# 通过
System.IO.FileSystem.AccessControl无法直接调用，需 P/Invoke
setxattr/
getxattrADS 在网络共享、ZIP 打包、Git 提交时默认丢失，
git config core.protectNTFS false才能保留，但多数 CI/CD 环境不启用
C# 中用 SQLite 做元数据索引最稳
绕过文件系统限制，把路径当主键，用嵌入式数据库存结构化元数据。SQLite 单文件、零配置、ACID 安全，配合
Microsoft.Data.Sqlite包，10 行内就能建表查写。
关键不是“能不能做”，而是表结构怎么设计才不易翻车：
主键必须是full_path TEXT PRIMARY KEY，不用 GUID 或 ID——路径变更时同步更新成本低，且避免硬链接、符号链接引发的歧义 元数据字段别预先定义列（如
project_id TEXT），改用
key TEXT, value TEXT的 KV 表，加
UNIQUE(full_path, key)约束，方便后期加字段 对高频查询字段（如
status）可建单独列并加索引，但不要为每个业务字段都建列——迁移和 ORM 映射会变重 读取时用
SELECT value FROM metadata WHERE full_path = @path AND key = 'reviewer'，比反序列化 JSON 字段更可靠、更易调试
ADS 在 Windows 上读写要注意的坑
FileStream操作 ADS 看似简单，但实际容易因路径编码、权限、UAC 导致静默失败或拒绝访问。 流名必须用冒号分隔，且不能包含
/ \ : * ? " |，
file.txt:meta合法，
file.txt:meta:2不合法（只允许一个冒号） ADS 不继承父目录权限，新建流后需显式调用
File.SetAccessControl，否则普通用户可能无法读取
Directory.GetFiles默认不返回 ADS，要用
File.Open尝试打开
path + ":stream_name"并捕获
FileNotFoundException判断是否存在 PowerShell 的
Get-Item file.txt -Stream *能看到流，但 C# 中
File.Exists("file.txt:meta") 返回 false——这是设计行为，不是 bug
跨平台方案别碰 FAT32/exFAT
FAT32 和 exFAT 完全不支持 xattr 或 ADS，任何基于扩展属性的设计在 U 盘、SD 卡、某些 NAS 上都会失效。如果目标设备类型不可控，必须降级处理：
检测文件系统类型：用DriveInfo.DriveFormat或
statvfs（Linux/macOS）判断是否为
FAT32或
exFAT遇到不支持的格式，自动 fallback 到同目录下
.filemeta.json文件，内容为
{"path": "a.txt", "tags": ["urgent"], "reviewed_by": "alice"}
这种 fallback 文件要加 .gitignore排除，且每次读取前检查 mtime 是否晚于原文件——避免缓存 stale 数据 别试图用 NTFS 的
$Extend\$UsnJrnl或 Linux 的 inotify 监控元数据变更：实现复杂、权限高、不可移植
真正麻烦的从来不是“怎么存”，而是“怎么让不同机器、不同时间、不同用户看到一致的元数据”。数据库路径映射+合理 fallback 是目前最可控的解法，其余都是权衡取舍后的妥协。
