这个问题我之前帮团队踩过坑，核心矛盾就是管理员权限安装时，进程的上下文是管理员而非当前登录的普通用户，导致代码里默认获取的AppData路径指向了管理员的配置目录。下面几个都是生产环境验证过的规范方案，按推荐程度排序：

1. 用Windows官方推荐的Active Setup（适合MSI安装包） #

如果你的安装包是用WiX、InstallShield这类工具制作的MSI包，这是最标准的做法：

• 把安装包配置为每机器安装（需要管理员权限），保证应用程序本身安装到公共目录（比如Program Files）。
• 将配置文件对应的组件标记为每用户组件，然后启用Active Setup功能。它会在每个用户第一次登录系统时，自动执行预设的操作（比如从公共目录复制配置文件到用户的AppData）。
• 好处是不仅能覆盖当前触发安装的用户，未来新增的用户登录时也能自动获取配置，完全符合Windows的权限模型。

2. 切换进程上下文到当前用户（适合自定义EXE安装程序） #

如果是自己写的EXE安装程序，可以通过API切换到当前交互式用户的上下文来写入配置：

• 先获取当前登录的普通用户的SID或用户名：可以用GetUserNameEx API，或者通过WMI查询Win32_ComputerSystem的UserName字段。
• 用CreateProcessAsUser API以该用户的身份启动一个子进程，在子进程里写入AppData目录。子进程的环境变量会自动继承该用户的配置，所以能正确获取到对应的AppData路径。
• 注意：管理员进程默认有足够权限模拟普通用户，但要确保子进程不会继承管理员的高权限，避免权限溢出。

3. 直接获取当前用户的Profile路径写入（快速解决方案） #

如果不想改太多安装逻辑，可以直接定位到当前用户的真实AppData路径：

• 通过命令行或API获取用户的Profile路径：比如命令行用wmic useraccount where name='%USERNAME%' get profilepath，代码里用GetUserProfileDirectory API。
• 手动拼接出%ProfilePath%\AppData\Roaming或%ProfilePath%\AppData\Local的路径，直接将配置文件写入这个位置。
• 提醒：管理员进程写入普通用户的Profile目录默认有权限，但最好先检查目标目录的权限设置，避免出现写入失败的情况。

不推荐的方案：遍历所有用户配置文件 #

你提到的遍历所有用户写入的方法确实不规范，原因有几个：

• 会涉及到废弃账户、域账户等不需要处理的用户，容易产生冗余文件。
• 写入其他用户的Profile目录可能触发Windows的权限限制，甚至违反安全策略。
• 无法覆盖未来新增的用户，扩展性差。

额外建议 #

如果是现代应用，推荐用MSIX打包格式，它原生支持管理员安装但为每个用户部署的模式，自动处理配置文件的隔离和分发，几乎不需要额外开发就能解决这个问题。

内容的提问来源于stack exchange，提问作者Stripes