windows服务启动时不继承用户环境变量，其变量取决于登录身份：localsystem/networkservice仅加载系统变量；指定用户账户需该用户首次交互登录后生成快照。推荐通过注册表hkey_local_machinesystemcurrentcontrolsetservices\environment添加变量，修改后重启服务生效。
windows 服务在启动时默认不继承用户登录会话的环境变量，也不加载用户配置文件中的 path、temp 等变量，因此直接修改用户或系统环境变量后，服务仍可能读不到——这是最常被忽略的根本原因。
服务启动上下文决定变量可见性
Windows 服务由 Service Control Manager（SCM）以特定账户身份启动，其环境变量来源取决于服务的“登录身份”：
-
LocalSystem：使用内置系统账户，仅加载系统级环境变量（如
%SystemRoot%、%windir%），不加载用户变量，也不读取注册表中HKEY_CURRENT_USER下的变量 - NetworkService / LocalService：同 LocalSystem 类似，环境隔离严格，不加载交互式用户变量
-
指定域/本地用户账户：仅在该用户首次以交互方式登录后，SCM 才会为其生成一次性的用户环境快照（含
USERPROFILE、APPDATA等），后续服务重启不再刷新；若该用户从未登录过，服务将只有最小化系统变量
推荐做法：通过注册表为服务单独注入变量
对特定服务生效、无需重启系统、不干扰其他进程的可靠方式是直接写入服务专属的注册表项：
- 定位路径：
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices\Environment - 若
Environment子项不存在，右键 → 新建 → 项，命名为Environment - 在该子项下新建字符串值（REG_SZ），名称即变量名（如
MY_CONFIG_PATH），数值数据填入路径（如D:ppconfig） - 多个变量可并列添加；支持引用已有变量，例如值设为
%SystemRoot%Temp，系统会自动展开 - 修改后必须重启该服务（非系统），新变量才会载入进程空间
避免踩坑的关键细节
以下操作看似合理，但实际无效或风险较高：
- 仅修改系统
Path变量后重启服务 → 失败：服务不会重新解析全局 Path，除非整个 SCM 重启（即重启系统） - 用
setx命令设置系统变量 → 不生效：setx 写入注册表后需新会话才加载，而服务不是“会话”进程 - 在服务程序内部用
SetEnvironmentVariable()API 设置 → 仅对当前进程有效，子进程不继承，且下次启动重置 - 依赖
%USERPROFILE%或%APPDATA%→ 高风险：LocalSystem 账户的USERPROFILE指向C:WindowsSystem32configsystemprofile，权限和路径常不符合预期
验证变量是否生效
服务启动后，可通过以下方式确认：
- 用 Process Explorer（Sysinternals 工具）打开服务进程 → 查看 Properties → Environment 标签页，直接看到完整变量列表
- 在服务代码中记录
GetEnvironmentVariable("MY_VAR")的返回值到日志 - 临时改服务为控制台应用（如 .NET 中调用
AttachConsole(ATTACH_PARENT_CONSOLE)），在 CMD 中手动启动观察输出
