NLog AtomicFile 在 macOS arm64 不写日志，核对目标扩展包

在 macOS arm64 上运行 .NET 10 程序，使用 NLog 6.1.4 的 AtomicFileTarget，ConcurrentWrites=true，却没有日志写入文件。若此前 NLog 5 的 FileTarget 能写，迁移后才出现这类表现，要核对真正负责原子追加的扩展包和原生实现，而不只看日志级别。

AtomicFileTarget 用来支持多个进程向同一文件追加。6.1.4 的非 Windows 路径依赖 Mono.Posix.NETStandard；该组合在 Apple Silicon 上遇到原生组件架构支持问题。其他操作系统或架构应分别核对，不能从这一台 macOS 的表现推断 Linux arm64 也一定失败。

要更新的是 NLog.Targets.AtomicFile

正式扩展包 NLog.Targets.AtomicFile 6.1.5 已移除 Mono.Posix.NETStandard 依赖，并在 Unix 追加实现中区分 macOS 与 Linux 的打开标志。6.1.5 是独立发布的扩展包，不能因为主 NLog 没有同名的 6.1.5 发行标签，就认定扩展修正不存在。

项目使用显式 PackageReference 时，对应项目文件片段为：

<PackageReference Include="NLog.Targets.AtomicFile" Version="6.1.5" />

将它合入已有引用或集中包版本配置，不要再叠一份重复定义。该扩展包声明的 NLog 依赖为 6.1.4；主包与目标扩展不是同一个版本检查。项目已使用包含修正的较新兼容版本时，不需要为此降回 6.1.5。

还要检查发布产物实际带上的目标程序集、包锁定结果与目标运行时，避免开发机引用已更新，发布目录仍留下旧扩展。仅看到主程序集版本变化，不能证明 AtomicFile 的追加实现已经更换。

不要用关闭并发写入代替原有契约

该目标在未启用 ConcurrentWrites、未保持文件打开，或每次替换内容等条件下，会走不同的文件流分支。把这些选项改掉可能碰巧恢复一条日志，但不能证明多进程追加仍然符合原来的要求。

若应用原本只有一个进程独占文件，可以按既有日志架构评估普通 FileTarget；如果多个进程确实共享文件，就不应只为让文件出现而悄悄取消所需的追加行为。也不要替换系统原生库或扩大目录权限，来补偿一个已确认需要更新的包实现。

启用应用现有的 NLog 内部诊断，把文件打开失败与过滤规则分开看。目录不存在、无权限、路径指向别处仍有各自的错误，升级平台实现不会自动修复这些条件。

归档数量要与写入问题分开核对

NLog 6 的新滚动归档逻辑与旧静态重命名模式不同。尤其在 AtomicFile 的滚动逻辑中，MaxArchiveFiles=1 不能照搬成“除了当前文件，再保留一份历史”；它可能在触发滚动时截断当前文件而不保留归档。

因此，恢复写入后还应按真实容量阈值检查保留策略。不要把后续滚动删除误判成“原生追加仍没修好”，也不要为了验收而删除已有日志或把阈值直接应用到生产文件。保留原配置，在独立文件上确认当前写入、多个写入方的记录完整性、滚动后的文件集合和正常关闭后的尾部记录。

成功标准是原 macOS arm64 发布产物能通过既有日志入口写到预期文件，所需的并发与归档约定仍满足。单进程只写一行成功，不能替代这些原本由目标承担的行为。