GetNamedSecurityInfo和SetNamedSecurityInfo是Windows底层ACL操作核心API，需手动构造EXPLICIT_ACCESS、正确处理NULL DACL、继承标志及UTF-8编码用户名，否则易现权限无效或访问拒绝。
GetNamedSecurityInfo 和 SetNamedSecurityInfo 是核心入口
Windows ACL 设置不走 CreateFile 或 SetFileAttributes，必须用 Advapi32.dll 提供的这两组 API。它们直接操作对象的安全描述符（SECURITY_DESCRIPTOR），绕过所有外壳层封装——这才是你想要的“底层”。GetNamedSecurityInfo 读取现有 DACL（或 SACL），SetNamedSecurityInfo 写入新 DACL；两者都要求你手动构造和释放 EXPLICIT_ACCESS 数组，不能只传个字符串权限。
常见错误现象：ERROR_INVALID_PARAMETER（传了空 ppsidOwner 却没设 OWNER_SECURITY_INFORMATION）、ERROR_ACCESS_DENIED（进程没“管理审核和安全日志”权限，或目标文件被其他进程独占打开）。
- 必须用
SE_KERNEL_OBJECT以外的类型调用：文件/目录用SE_FILE_OBJECT，注册表用SE_REGISTRY_KEY - 不要传
NULL给ppsidOwner/ppsidGroup—— 即使你不改 owner，也得先用GetNamedSecurityInfo拿到原值再传回去，否则写入失败 - 调用前确保进程有
SE_TAKE_OWNERSHIP_NAME权限（对非自己拥有的文件）或SE_SECURITY_NAME（修改 SACL）——通常需以管理员身份运行
BuildExplicitAccessWithName 构造权限项时容易漏掉继承标志
用 BuildExplicitAccessWithName 快速生成 EXPLICIT_ACCESS 结构体很方便，但它默认不设任何继承标志。如果你要让子目录/文件自动继承权限，必须手动把 OBJECT_INHERIT_ACE 和 CONTAINER_INHERIT_ACE 或者两者都或（|）进 grfInheritance 字段——否则设置只生效于当前文件，新建的子项完全不受控。
使用场景：给一个项目根目录设置“开发组可读写、其他人只读”，且希望所有新增源码文件自动继承该策略。
-
grfInheritance = OBJECT_INHERIT_ACE | CONTAINER_INHERIT_ACE→ 目录和文件都继承 -
grfInheritance = OBJECT_INHERIT_ACE→ 只有文件继承（比如你只想控制 .cpp/.h，不希望子目录再套一层 ACL） - 别用
BuildExplicitAccessWithSid替代——它不接受宽字符用户名，而BuildExplicitAccessWithName支持L"DOMAIN\User"格式，更贴近实际部署
SetNamedSecurityInfo 返回 ERROR_SUCCESS 但权限没变？检查 DACL 是否为 NULL
这是最隐蔽的坑：如果目标文件当前没有 DACL（即 DACL 为空指针），系统默认“拒绝所有访问”。此时你调用 SetNamedSecurityInfo 传入一个合法 DACL，API 返回 ERROR_SUCCESS，但资源管理器里看“安全”选项卡仍显示“无权限条目”。因为 Windows 把空 DACL 和“无 DACL”视为不同状态，而 SetNamedSecurityInfo 在 pDacl 非空时，会把原 DACL 替换为你传入的，但如果原对象压根没 DACL，你的新 DACL 就成了唯一来源——逻辑没错，但 UI 不刷新或缓存未清，容易误判失败。
验证方法：用 GetNamedSecurityInfo 拿回 ppDacl，再调 GetAclInformation 看 ActualAceCount 是否大于 0。
- 调用前先用
GetNamedSecurityInfo拿原始 DACL，确认是否为NULL；若为NULL，构造新 DACL 时务必包含至少一条显式允许规则（如GENERIC_READ给SYSTEM），否则写入后文件将彻底不可访问 - 不要依赖资源管理器实时刷新——改完后用
icacls "path" /verify命令行验证 - 注意：
SetNamedSecurityInfo不支持原子性更新；如果中途失败，旧 DACL 已被覆盖，无法自动回滚
WideCharToMultiByte 转换用户名时编码必须用 CP_UTF8
虽然 Windows API 文档说 BuildExplicitAccessWithName 接受 ANSI 字符串，但实际在 Unicode 系统（所有现代 Windows）上，它内部会用当前 ACP 解码。一旦用户名含中文、emoji 或域账号（如 L"contoso\张三"），用默认 ACP（如 GBK）转换会导致乱码，最终 ACL 条目匹配失败——表现为“添加成功但用户仍无权限”。
正确做法是统一用 UTF-8 编码路径和用户名，并通过 WideCharToMultiByte(CP_UTF8, ...) 显式转出字节流。这和 SetNamedSecurityInfo 的文档行为不一致，但实测唯一稳定方案。
- 不要用
std::string存用户名再传给 API——C++ 字符串默认不保证 UTF-8，尤其 VS 默认是 MBCS - 所有宽字符串（
LPWSTR）输入前，先用WideCharToMultiByte(CP_UTF8, 0, wszName, -1, nullptr, 0, nullptr, nullptr)测长度，再分配缓冲区 - 若调用
SetNamedSecurityInfo后返回ERROR_INVALID_NAME，90% 是用户名编码问题，不是拼写错
ACL 不是开关按钮，它是多层嵌套结构：SID → ACE → DACL → SECURITY_DESCRIPTOR → 对象。每层都有自己的生命周期和所有权规则，漏掉一次 LocalFree 或多一次 HeapAlloc，都会让后续调用静默失败。别信“设完就完事”，得逐层验证。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
