Windows 的“用户与组管理”是我每次装完系统、搭好一台服务器或帮别人处理电脑时都绕不开的一步。无论是公司给新员工开账号、限制某台机器只能由指定几个人登录，还是想把自己电脑上的标准用户和管理员分开，本质上都在做同一件事：搞清楚谁能用这台设备、能碰哪些资源。
这篇文章不打算写成干巴巴的官方文档，我把平时用得最多的图形界面工具、老牌的 net 命令，以及现在更推荐的 PowerShell 管理方式都串起来讲一遍。里面有具体命令、使用场景，还有我实际踩过的一些坑，适合刚接触 Windows 系统维护的人，也适合已经管理过几台机器、想梳理一下思路的运维朋友。
1. 管理用户与组的整体设计思路
动鼠标在系统里“新建用户”这件事三分钟就能学会，真正难的是想清楚为什么建、建成什么样、给多大权限。如果没有一套清晰思路，账户会越堆越多，权限会越给越乱。
1.1 为什么说“组”才是权限分配的主角
在 Windows 里，所有用户状态的不同之处在于它默认的行为方式，以及它能访问的资源范围。如果直接对某个用户单独授予文件共享或 NTFS 访问权，系统完全可以做到，但这种做法在机器数量增多后会迅速失控。举个例子：一台办公电脑上有五个人需要读取某个共享文件夹，假如这五个人分属不同部门、又有不同岗位变动，管理员就得在共享权限里逐个添加、逐个移除，改一个走一个人就得动一次权限列表。
组是用来解决这个问题的。把访问需求相同的账户放进同一个组，然后把权限分配给组，整组的人同时获得权限，有人离职或调岗时只改组成员关系就行。这种把“用户”和“权限”解耦的做法，是 Windows 用户管理里最基本也最重要的一条原则。
1.2 我给客户和项目定的账户管理约定
长期做系统维护之后，我逐渐形成了一套约定，这些约定不太会写进微软的官方文档，但对减少麻烦非常有用：
- 每个账户对应一个自然人，不建“公共账号”。多人共用同一个管理员账户，出了问题你根本不知道是哪个人干的。
- 日常操作尽量用标准用户，只有安装软件、修改系统设置时才需要管理员权限。UAC 弹窗时再输入那一次管理员口令，其实成本很低。
- 命名格式一定要提前定好，最好和公司内部通讯录的工号或姓名拼音对应。比如“zhangsan”“wangwu”，避免随意起名。
- 离职或长期不用的账户，先禁用、再观察，确定不需要后删除。直接删掉可能会影响该账户遗留文件的归属标识。
- 密码不告诉第二个人。真有紧急情况，用后重置密码，不要靠共享密码来维持运转。
这套约定看起来很基础，但绝大多数权限事故和找不着主的垃圾账户，都是因为这些基础约定没做到位。在一台个人电脑上，这些约定可以简化成一句话：自己平时永远别用 Administrator 登录，分开管理员账户和日常账户。
2. 用户账户与内置组，这些基础概念一次弄懂
真正上手操作之前，有几个概念一定要分清楚。我见过不少朋友在“本地用户”和“域用户”上绕晕，也见过因为在理解 SID 上缺了一块，删了账户重建之后旧的权限列表就失效了，半天想不通为什么。
2.1 本地用户与 Active Directory 用户先分清
Windows 的用户账户在工作组环境下是“本地账户”。它只存在于某一台电脑的系统本地安全数据库里，账户名、密码、所属组都只对这台机器有意义。你用 net user 在这台机器上建账户，换一台电脑是没有这个用户的。
而加入域的机器就不一样了。域账户存在于 Active Directory 数据库里，一台域里的机器可以随时验证这个账户是否存在，管理员在域里集中管理密码和组成员关系。你可以简单理解成：本地账户像门禁卡上写好的开锁权限，只开这一扇门；域账户像公司统一发的员工卡，所有联网的门禁都认。
日常维护中，两者常要区分对待。我在维护只有三五台设备的办公室时，很多系统环境把整个办公环境放到域里面集中管理，用户加入不同的组后，每次登录到哪台机器都自动带着自己的身份。单独管理一台不加入的设备时，就要用本地用户。分清两者再动手操作，至少不会出现“为什么我在域里改了用户密码，这台电脑上还是用不了”这类困惑。
2.2 Windows 内置账户与内置组一图看懂
Windows 在安装完系统后会自动创建几个内置账户：
| 内置账户 | 状态 | 主要作用 |
|---|---|---|
| Administrator | 默认禁用 | 系统内置最高权限账户，SID 末尾一般是 500，可应急恢复系统 |
| Guest | 默认禁用 | 来宾账户，SID 末尾一般是 501，很少直接启用 |
| DefaultAccount | 默认禁用 | 系统保留的系统账户 |
| WDAGUtilityAccount | 默认禁用 | 供 Windows Defender 应用防护使用的账户 |
内置账户里要格外留意的是 Administrator。它在这个系统里拥有几乎所有权限，但默认被禁用，这样我们平时的操作都被强制走标准用户身份。如果因为各种原因把它启用了，那一刻开始，这台机器的权限边界就会变得很模糊。
再来看内置组。本地用户和组里有一批系统预定义的内置组，常见的有这些：
| 内置组名 | 默认权限范围 |
|---|---|
| Administrators | 管理员组，几乎不受限制，可安装软件、修改系统设置、管理其他用户 |
| Users | 标准用户组，可运行日常程序，不能修改系统级设置 |
| Guests | 来宾组，权限比 Users 更小，仅适合临时登录 |
| Remote Desktop Users | 允许通过远程桌面登录 |
| Backup Operators | 可以备份和还原文件，包括部分系统文件 |
| Hyper-V Administrators | 可以管理 Hyper-V 虚拟化功能 |
| Performance Monitoring Users | 可访问系统性能计数器数据 |
这里有一个容易踩的坑：Power Users 组在 Windows XP 时代非常常见，以为它有较高的系统控制权，但在 Windows 10 和 Windows 11 里它只是一个保留组，默认不分配任何特殊权限。网上很多老教程让你把用户加进 Power Users，实际加完往往没什么效果。日常使用中，你真正需要关注的组一般不超过四个：Administrators、Users、Remote Desktop Users、Backup Operators。
2.3 从 SID 理解为什么账户删了重建，权限却“丢了”
SID（安全标识符）是 Windows 用来识别主体的内部编号，每个人的账户都有一个唯一 SID，权限列表里记录的并不是“zhangsan”这个名字，而是 zhangsan 对应的 SID。这个机制特别重要，因为它解释了权限管理的很多怪现象。
举个例子：某员工的账户出问题，管理员把他账户删除，又用同样的用户名重新建了一个。文件权限列表里明明写的是 zhangsan，但 zhangsan 却访问不了那个文件夹。这是因为新账户的 SID 和旧账户的 SID 完全不一样，权限列表里的旧 SID 成了无主之物。系统不认“名字一样就当同一个人”，只认 SID。
所以，遇到用户账户损坏或忘记密码，尽量用“重置密码”而不是“删除重建”。如果非要重建，就得把旧账户的配置文件、权限归属重新关联一遍，过程颇为折腾。检查某个用户属于哪些组、对应哪个 SID，可以用 PowerShell 里Get-LocalUser | Select-Object Name,SID来查看，命令行比图形界面方便很多。
3. 动手实操：图形界面与命令行工具如何分工合作
操作层面，Windows 给管理员提供了好几条路。图形界面适合偶尔点一点，命令行和 PowerShell 适合批量操作、远程操作和做自动化。我的习惯是：看得见摸得着的动作，用图形界面；涉及状态、判断和批量改，用命令行。
3.1 lusrmgr.msc 与计算机管理的基本操作
在 Windows 10/11 专业版或更高版本里，打开“计算机管理”—“本地用户和组”，就能看到用户和组的列表。也可以直接在运行框输入lusrmgr.msc打开独立管理窗口，这是最传统的方式，看起来最直观。
在用户列表里，右键可以设置密码、禁用账户、重命名、删除，以及查看“隶属于”的组。组列表里则可以看这个组里面有哪些成员。这些操作门槛很低，但有一个需要特别注意的限制：不能重命名或删除当前登录使用的账户。系统不允许你把自己正在用的账户就地删除，想删的话得先切到别的账户。
另外，lusrmgr.msc在 Windows 家庭版里是被刻意隐藏掉的，打开后系统会提示找不到该工具。比较老的版本里还能通过新建一个lusrmgr.msc管理单元曲线实现，新系统里基本没什么可靠办法。家庭版需要用更轻量的工具，比如运行netplwiz，这个命令始终可用，能完成添加用户、改密码、改组成员等核心操作。
3.2 用 net user 与 net localgroup 快速完成日常增删改
net user是命令提示符时代就有的老牌命令，在批处理脚本里至今很实用。我不靠记忆背一大堆参数，而是记住一个小套路：不知道某个命令支持什么，直接敲net user /?或者net localgroup /?就有完整说明。
查看当前机器上有哪些用户：
net user创建用户 zhangsan，密码设为P@ssw0rd123，并指定密码永不过期：
net user zhangsan P@ssw0rd123 /add /passwordchg:yes /expires:never把 zhangsan 加入管理员组：
net localgroup administrators zhangsan /add查看本地组列表：
net localgroup我把net user当成快速侦察工具，用它来检查账户是否启用、密码是否需要修改、账户是否到期，一条命令全部显示出来：
net user zhangsan输出的内容包含全局参数、本地组成员身份、密码相关信息，信息量比在图形界面里到处点要高得多。不过 net user 在用户账户管理上能力有限，它没办法直接修改用户的全名、描述、配置目录等信息，这些方面 PowerShell 更为灵活。
3.3 wmic useraccount 已被淘汰，切换到 PowerShell
很多老资料里会出现wmic useraccount get name,sid这类命令。wmic 确实能查出用户与其 SID 的对应关系，从 Windows 11 开始 wmic 已经被彻底移除，Windows 10 的较新版本也默认是过时状态，部分系统直接执行会提示找不到路径。建议新环境统一用 PowerShell 替代。
查看所有本地用户的名称、SID 和状态：
Get-LocalUser | Select-Object Name, SID, Enabled查看某个用户属于哪些组：
Get-LocalGroup | Where-Object { $_.Members -like "*zhangsan*" } | Select-Object Name新建用户：
New-LocalUser -Name "zhangsan" -Password (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) Add-LocalGroupMember -Group "Users" -Member "zhangsan"重新启用 Guest 或管理员账户：
Enable-LocalUser -Name "Administrator"给用户设置密码变更、强制下次登录时修改密码等，PowerShell 里的参数也比 net 命令更直观。把同样的操作放在十几台机器上时，PowerShell 的批量能力立刻凸显出来。
4. 批量创建用户、分配组与常见运维场景落地
单台机器的用户管理，用上面几条命令就够了。但如果你是在帮某家公司维护二十几台电脑，或者要为新来的项目组统一开通账号，真正需要的是“批量处理”和“可重复执行”。
4.1 用 PowerShell 批量导入用户并加入指定组
我经常这么干：先准备一个 CSV 文件，每一行放一个人的姓名拼音、显示名、加入的组。然后用 PowerShell 一键导入。
这里先给出一个演示脚本，创建用户并在首次登录时强制改密码：
$users = Import-Csv .\users.csv foreach ($u in $users) { $securePass = ConvertTo-SecureString "TmpPass!2024" -AsPlainText -Force New-LocalUser -Name $u.UserName -FullName $u.DisplayName -Password $securePass Add-LocalGroupMember -Group $u.Group -Member $u.UserName Set-LocalUser -Name $u.UserName -PasswordNeverExpires $false Write-Host "已创建: $($u.UserName) -> $($u.Group)" }CSV 内容类似这样：
UserName,DisplayName,Group zhangsan,张三,Users lisi,李四,Remote Desktop Users脚本执行前要确认已用管理员身份的 PowerShell 运行。Import-Csv会把文件内容变成对象，ConvertTo-SecureString把明文字符串转成安全密码，New-LocalUser创建账户，Add-LocalGroupMember把用户放进组。执行完以后，我习惯再用一次Get-LocalUser抽查几个账户，确认状态正常。
这种批量操作最大的价值不在“快”，而在“可复现”。脚本文件留着，下次新员工入职改改 CSV 就能直接用，不用重新点一遍图形界面。如果机器规模再大一些，还可以把这些脚本放进统一纳管平台里定时执行，但那是另一个话题了。
4.2 密码策略、账户锁定与状态控制
用户管理不只是建号删号，密码策略和账户状态同样重要。Windows 默认策略通常要求密码达到一定长度并满足复杂度要求，过弱口令会直接在创建时被拒绝。
查看当前密码规则：
net accounts强制所有用户密码最短周期为 7 天、最长周期为 30 天：
net accounts /minpwlen:8 /maxpwage:30 /minpwage:7账户锁定策略防止无休止猜密码，在“本地安全策略—账户锁定策略”里可以看到设置项，也可以用命令行修改对应值。我维护的办公环境里，一般会把“账户锁定阈值”设置成 5 次，锁定持续时间 10 到 15 分钟。设置得太短，误输密码的人要多等；设置得太长，恶意尝试的窗口就变大了。这个值没有绝对标准，跟现场情况走。
账户状态的管理，PowerShell 可以直接处理：
Disable-LocalUser -Name "zhangsan" Enable-LocalUser -Name "zhangsan"从运维角度看，离职人员的账号第一时间禁用，比删除更稳妥。禁用后这个账户不能登录，但它的 SID、配置和数据还在原处，等确认没问题后再走删除流程。
4.3 审计本地管理员组
管理员组是整台机器权限最大的地方，也是最容易被忽视的组。我给客户排查问题时，经常发现一台电脑的管理员组里有五六个账户，其中一半都不知道是什么时候加进去的。
检查管理员组成员：
Get-LocalGroupMember -Group "Administrators"快速查出所有管理员账户：
Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource把某个账户从管理员组移除：
Remove-LocalGroupMember -Group "Administrators" -Member "zhangsan"我建议每季度或每半年做一次管理员组审计。规则就一条：管理员组里存在的每个账户，都必须能对应到一个具体责任人。没有明确责任人、长期未使用、看起来像是临时加进去的账户，都应当清理掉。这个方法在只有 10 人的小办公室和上百台服务器的更大环境里同样适用，把“最小权限”落到实际行动中。
5. 踩坑记录与排查速查
管理用户和组这件事，操作本身并不难，真正的坑往往藏在细节里。我在多次维护中积累了一些排错经验，整理出来供参考。
5.1 常见报错与解决方法
| 现象 | 常见原因 | 解决办法 |
|---|---|---|
| 提示“找不到用户” | 使用了本地组命令去添加域账户，或者把用户名的域/主机名字段写错 | 确认账户类型，域环境用net group，本地环境用net localgroup；用Get-LocalUser核对用户全名 |
| 创建用户时提示密码不符合策略 | Windows 默认要求密码复杂度和最小长度 | 改用包含大小写字母、数字、符号组合的强密码，通常至少 8 位 |
| 无法删除 Administrator 或 Guest | 内置账户受系统保护 | 不建议强行删除；用禁用和重命名替代，保持安全即可 |
| 重命名账户时失败，提示正在使用 | 不能修改当前登录用户的名称 | 切换到另一个管理员账户再执行重命名操作 |
| 拿 U 盘从旧电脑拷贝用户配置文件 | 新旧 SID 不一致，新系统无法直接继承配置 | 用系统自带的配置转移方式，或者手工迁移个人文件夹，重建用户后重新关联权限 |
| 家庭版打不开 lusrmgr.msc | 家庭版不包含“本地用户和组”完整管理单元 | 改用 net user / net localgroup / netplwiz / PowerShell |
| 修改组后权限没有立即生效 | 用户已登录会话中的令牌没有刷新 | 注销再重新登录，或者重启机器 |
还有一点容易被忽略：net user 里显示的用户名是“用户名”，但用户可能还有“全名”。加入某个组时要用的是用户名，不是全名。我见过有同事在Add-LocalGroupMember里填了显示全名，报错后还找了半天原因，其实就是没分清这两个字段。
5.2 权限和安全方面的几条经验
管理账号的最终目的不是为了把界面搞得好看，而是为了守住权限边界。下面这几条是我在实际维护中最坚持的操作纪律：
- Administrator 内置账户保持禁用状态。真的需要应急时再启用，用完立刻禁用。
- Guest 账户永远保持禁用。在大多数办公环境里，游客账户根本没有存在价值。
- 不直接给普通员工管理员权限。日常改壁纸、装打印机驱动这类需求，让管理员验证一次并不烦人，反而能避免很多无效故障。
- 密码重置前先确认账户不是被锁定了。账户被锁定和密码错误是两码事，直接重置密码但不解锁，用户还是登录不了。
- 谨慎开通远程桌面权限。需要远程协助的用户加入 Remote Desktop Users 组即可，不要为图省事直接塞进管理员组。
权限管理上还有一个容易被忽视的原则，叫“权限边界清晰化”。比如某台服务器上只有一个运维账户，那么这个账户做普通日常操作和做高权限操作时，如果条件允许，最好拆分。服务器上尽量不频繁登录管理员账户，平时用标准权限做日常巡检，需要部署软件时再提起权限。Windows 的 UAC 机制就是为了配合这种思路而存在的，不要一上来就关掉它。
5.3 从备份和恢复角度看用户数据安全
用户账户管理要面对的另一个大事是数据恢复。很多人以为把 C 盘里的用户文件夹拷出来就能迁移用户，实际操作中问题很多。用户名一样不代表配置文件有效，文件夹里的 NTFS 权限经常和原账户的 SID 绑定。这种场景下，即使我们复制了很久，新系统中也可能无法正常使用或弹权限报错。
正确做法是优先用系统自带的备份功能或专业迁移工具，让系统自己处理用户 SID 和配置文件之间的关联关系。如果只能手工做，至少要把“用户配置文件”整个目录连同 NTFS 权限一起复制，新机器重新建立同名账户后，再用“高级系统设置—用户配置文件—复制到”的方式关联，这样才能实现比较平滑的迁移。
除此之外，我还会在清理用户前先导出该用户桌面、文档、下载目录中的数据，至少确认没有遗留重要文件。删除账户只是清理账号本身，但数据资产必须同步检查。实际操作中，我会先禁用账户，再把相关数据压缩归档保存一个月以上，没问题后再删。
最后再分享一点我的体会
系统里最值钱的东西不是装了多复杂的软件，而是这台设备上有哪些人、谁有权限动什么。用户与组管理如果只是停留在“会建账号”的层面，那很多隐患会在某台服务器出问题时突然爆发出来。我实际操作中的习惯是：每次维护完都顺手做一次管理员组审计，确认没有多出来的陌生账户，再检查一遍 Guest 状态是否被误开启，最后在操作日志里记一笔什么时间、谁、做了什么改动。这套流程执行起来也就几分钟，但长期积累下来，维护工作会轻松非常多。
