EventLog 写入需注意权限、源注册和跨平台兼容：运行账户须有日志写入权限，源名须合法且提前注册，.NET Core+ 仅 Windows 支持 EventLog，跨平台应使用 ILogger 抽象并条件编译。
用 EventLog 写入 Windows 事件查看器，不是所有账户都有权限
直接调用 EventLog.WriteEntry 很容易报错 System.Security.SecurityException 或 UnauthorizedAccessException——这不是代码写错了，是当前运行账号没被授予写入系统日志的权限。开发时用管理员身份运行 Visual Studio 或 dotnet CLI 才可能成功；部署到 Windows 服务或 IIS 时，得确认服务账户（比如 NT SERVICEYourServiceName）已加入 Event Log Readers 组，且目标日志（如 Application）允许该账户写入。
实操建议：
- 优先写入
Application日志（默认允许大多数用户写），别一上来就往Security或System里写 - 创建新日志源前，先用
EventLog.SourceExists("MyApp")检查，避免因缺少管理员权限导致CreateEventSource失败 - 如果必须自定义日志（非 Application），只能由安装程序以管理员身份调用
EventLog.CreateEventSource，普通运行时无法创建
EventLog.Source 必须提前注册，且不能含空格或特殊字符
日志源（Source）不是随便起个名就能用的。它本质是注册表项（HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLogApplicationYourSource），注册时名字会自动转为全大写、去空格、去点号。比如你传 "My.App 2.0"，实际注册成 "MYAPP20"，后续写日志时若仍用原字符串，就会找不到源，抛出 ArgumentException: The source was not found。
实操建议：
- 源名只用大小写字母、数字、下划线，长度不超过 8 个字符（兼容旧系统）
- 注册和写入必须用完全相同的字符串，建议统一定义为常量：
private const string SourceName = "MyAppCore"; - 本地调试时可手动用 PowerShell 注册：
New-EventLog -LogName Application -Source MyAppCore，省去代码注册环节
写日志时别忽略 eventID 和 eventType，它们决定筛选和告警逻辑
很多开发者只传消息字符串，结果在事件查看器里全是“信息”级别、ID 为 0 的条目，根本没法按错误类型过滤。Windows 事件系统靠 eventID（整数）和 eventType（EventLogEntryType.Error 等）做分类聚合，监控工具（如 WMI、Azure Monitor）也依赖这两个字段触发告警。
实操建议：
- 为不同场景分配固定
eventID：比如登录失败 =1001，数据库连接超时 =2005，避免每次 new Random().Next() - 错误必须用
EventLogEntryType.Error，警告用Warning，别全塞进Information - 消息体别超过 32766 字符，超长会被截断，敏感数据（密码、token）禁止写入日志
.NET Core/.NET 5+ 在非 Windows 平台不支持 EventLog
System.Diagnostics.EventLog 是 Windows 特有 API，.NET Core 3.1 起才通过 Windows 兼容包提供有限支持；到了 .NET 5，它被移到 Microsoft.Extensions.Logging.EventLog 包中，且仅限 Windows 运行时加载。你在 Linux 容器里跑这段代码，编译能过，运行直接 TypeLoadException。
实操建议：
- 跨平台项目改用
ILogger抽象，配合EventLogLoggerProvider（仅 Windows 启用），其他环境走 Console 或 File 提供商 - 条件编译不可少：
#if WINDOWS包裹EventLog相关逻辑，否则 CI 构建到 Linux agent 会失败 - 不要假设
Environment.OSVersion.Platform == PlatformID.Win32NT就万事大吉——WSL2 下这个判断为 true，但EventLog仍不可用
