本地文件读取必须绕开file.readalltext，改用filestream+streamreader显式指定utf8编码，路径来自配置且限白名单目录，读取后立即脱敏/校验；ml.net/tensorflow.net加载需using包裹、避免复用上下文；模型更新前须sha256签名校验并原子写入临时目录；禁用filesystemwatcher，改用定时轮询或命名管道触发训练。
本地文件读取必须绕开 File.ReadAllText 直接暴露路径
联邦学习里，每个客户端（比如医院、银行）只允许在本地处理自己的数据，绝不能把原始文件路径或内容传给中心服务器。但很多人一上来就用 File.ReadAllText("data.csv")，这看似简单，实则埋雷：路径硬编码、异常未隔离、字符编码不一致，还可能触发 .NET 的文件访问安全策略（尤其在受限容器或沙箱环境）。
正确做法是把文件 I/O 封装进受控上下文，明确区分“数据加载”和“数据上传”两个阶段：
- 用
FileStream+StreamReader显式指定Encoding.UTF8，避免 BOM 或 ANSI 导致解析错位 - 路径必须来自配置项（如
config.LocalDataPath），而非字符串字面量；上线前检查该路径是否在白名单目录内（例如只允许"./data/"子路径） - 读取后立即做脱敏/采样/哈希校验，绝不让原始字节流裸露到网络序列化环节
TensorFlow.NET 或 ML.NET 加载本地 CSV 时如何避免内存泄漏
联邦训练常需反复加载本地小批量数据（比如每次迭代读一个 batch_001.csv），但直接用 MLContext.Data.LoadFromTextFile 或 TF_DataSet.FromCsv 容易累积未释放的 IDisposable 资源——尤其在 Windows 上，FileStream 占着句柄不放会导致后续读取报 IOException: The process cannot access the file。
关键不是“怎么读”，而是“读完立刻切干净”：
- 所有数据加载逻辑必须包裹在
using块中，哪怕只是临时IDataView或NDArray - 如果用
ML.NET，别复用同一个MLContext实例跨轮次；每轮新建轻量级实例，避免缓存污染 - 对
TensorFlow.NET，调用Dispose()前先确认没有张量正被 GPU 引用（常见于session.Run()后忘记output.Dispose()）
本地模型更新文件（如 model.weights.bin）写入前必须校验签名与完整性
联邦学习中，客户端收到中心下发的模型参数后要本地训练、再回传增量更新。但攻击者可能篡改本地磁盘上的 model.weights.bin，导致恶意梯度上传。C# 默认不校验文件来源，File.WriteAllBytes 写入即生效，风险极高。
真实生产环境必须加两道锁：
- 写入前比对中心下发的 SHA256 签名（存在
update.manifest.json中），用SHA256.Create().ComputeHash(stream)校验本地文件内容 - 写入目标路径必须是临时目录（如
Path.GetTempPath() + "fedtmp_" + Guid.NewGuid()），校验通过后再原子性地File.Move到正式位置 - 禁用任何
File.WriteAllText直接覆盖主模型文件的操作；所有更新必须走带版本号的子目录（如./models/v2.1.0/），旧版本保留至少一轮供回滚
Windows 上 FileSystemWatcher 监听本地数据变更会干扰联邦训练节奏
有人想用 FileSystemWatcher 自动触发本地训练——比如检测到新 data_202405.csv 就跑一轮 TrainLocalModel()。但这个类在高IO场景下极不稳定：事件重复触发、丢失事件、甚至阻塞主线程，导致训练任务堆积或漏训。
联邦学习要求确定性执行窗口（比如每天凌晨 2 点统一启动），而不是靠文件系统信号驱动：
- 完全弃用
FileSystemWatcher，改用定时轮询 + 文件时间戳比对（File.GetLastWriteTimeUtc(path) > lastRunTime） - 轮询间隔不低于 30 秒，且每次只处理一个最新文件，避免并发读同一份 CSV
- 若真需实时响应，用命名管道（
NamedPipeServerStream）接收中心下发的触发指令，而非监听磁盘
本地文件永远只是数据容器，不是控制信道。联邦学习的协调逻辑必须收口在通信层，而不是散落在每个客户端的文件系统行为里。
