应采用外挂sqlite数据库映射文件路径存储结构化元数据，主键用full_path，字段用kv表设计，并对高频查询字段单独建索引；不支持xattr的文件系统（如fat32）则fallback至同目录.json文件。
文件系统不支持自定义元数据，怎么办
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/Invokesetxattr/getxattr - ADS 在网络共享、ZIP 打包、Git 提交时默认丢失，
git config core.protectNTFS false才能保留，但多数 CI/CD 环境不启用
C# 中用 SQLite 做元数据索引最稳
绕过文件系统限制，把路径当主键，用嵌入式数据库存结构化元数据。SQLite 单文件、零配置、ACID 安全，配合 Microsoft.Data.Sqlite 包，10 行内就能建表查写。
关键不是“能不能做”，而是表结构怎么设计才不易翻车：
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
- 主键必须是
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 是目前最可控的解法，其余都是权衡取舍后的妥协。
