windows下应优先使用getcommandlinew获取原始命令行字符串，它返回含程序路径及所有参数的宽字符只读缓冲区；若需参数数组，须调用commandlinetoargvw解析并用localfree释放内存；linux则需用read一次性读取/proc/self/cmdline二进制内容，按'\0'切分。
Windows 下用 GetCommandLineW 获取原始命令行字符串
Windows 提供了 GetCommandLineW（宽字符）和 GetCommandLineA（ANSI），但后者在非英文系统上容易乱码，必须优先用 GetCommandLineW。它返回的是未经解析的原始命令行字符串，包括程序路径和所有参数，且**不自动跳过可执行文件名**——这点和 argv 不同，需要手动拆分。
常见错误是直接拿 GetCommandLineW 结果当参数数组用，结果把程序路径也当成第一个参数；或者用 CommandLineToArgvW 解析后没调用 LocalFree 导致内存泄漏。
-
GetCommandLineW返回值不能 free，它是只读静态缓冲区 - 若需分离参数，必须调用
CommandLineToArgvW，它返回LPWSTR*，使用后必须LocalFree - 注意：
CommandLineToArgvW对含空格路径、引号嵌套等场景解析正确，比手写 split 可靠得多
LPWSTR* argv_w = CommandLineToArgvW(GetCommandLineW(), &argc); // ... 使用 argv_w[0] 到 argv_w[argc-1] LocalFree(argv_w); // 必须！
Linux 下读取 /proc/self/cmdline 的二进制格式
Linux 没有统一 API，标准做法是读 /proc/self/cmdline：它不是普通文本文件，而是以 \0 分隔的 C 字符串序列，末尾无换行。直接用 fgets 或 readline 会截断第一个参数，因为遇到首个 \0 就停了。
常见错误是当成普通文本读，或用 std::ifstream 默认按行读取，结果只拿到程序名；还有人误以为 argv 和这里内容总是一致——其实如果进程调用过 prctl(PR_SET_NAME) 或被 setproctitle 修改过，/proc/self/cmdline 仍保持原始值，而 argv[0] 可能已被覆盖。
- 必须用
read或fread一次性读完全部内容，再按\0手动切分 - 读取长度建议至少 4096 字节，但实际应循环读直到
read返回 0（/proc/self/cmdline总是能完整读出） - 注意：该文件在容器中可能不可读（如某些 gVisor 或严格 seccomp 环境）
int fd = open("/proc/self/cmdline", O_RDONLY);
if (fd != -1) {
std::vector<char> buf(4096);
ssize_t n = read(fd, buf.data(), buf.size() - 1);
close(fd);
if (n > 0) {
buf[n] = '\0';
const char* p = buf.data();
while (p <h3>跨平台封装时别依赖 argc/argv 的“原始性”</h3>
<p>很多人想写个 <code>get_original_cmdline()</code> 函数，直接返回 <code>argv</code> 数组。这是错的：C++ 标准只要求 <code>argv[0]</code> 是程序名，其余参数由启动环境提供，但操作系统或运行时库可能已修改它。例如 Windows 上某些 IDE 启动进程时会注入调试参数；Linux 下 systemd 服务通过 <code>ExecStart=</code> 启动时，<code>argv</code> 是经 shell 展开后的结果，而 <code>/proc/self/cmdline</code> 是未展开的原始字符串。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6580" title="Linux installer"><img
src="https://img.php.cn/upload/skill/000/000/081/179101817874041.jpg" alt="Linux installer" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6580" title="Linux installer" class="overflowclass">Linux installer</a>
<p class="overflowclass">先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6580" title="Linux installer" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<p>真正“原始”的命令行，在 Windows 是 <code>GetCommandLineW</code>，Linux 是 <code>/proc/self/cmdline</code>，二者语义一致；<code>argv</code> 只是解析后的便利视图，且不可逆。</p>
<ul>
<li>不要试图在 Linux 上用 <code>argv</code> 替代 <code>/proc/self/cmdline</code> 做审计或日志记录</li>
<li>Windows 下若程序被 <code>CreateProcess</code> 以 <code>CREATE_NO_WINDOW</code> 启动，<code>GetCommandLineW</code> 仍有效，但 <code>argv</code> 可能为空（取决于 CRT 初始化方式）</li>
<li>跨平台库（如 Boost.Process）内部也是分别走这两条路径，没有通用 syscall</li>
</ul>
<h3>权限与容器环境下的可访问性问题</h3>
<p>Linux 下读 <code>/proc/self/cmdline</code> 看似简单，但在生产环境中常失败：容器默认挂载 <code>procfs</code> 时可能禁用 <code>hidepid=2</code>，导致非 root 进程读不到其他字段；更常见的是，某些安全加固策略（如 Kubernetes PodSecurityPolicy 或 SELinux 策略）会显式 deny 对 <code>proc</code> 的读取。</p>
<p>Windows 相对稳定，但 UWP 应用或沙盒环境（如 Windows Sandbox）中，<code>GetCommandLineW</code> 可能返回空字符串或引发访问异常。</p>
<ul>
<li>务必检查返回值：Linux 下 <code>open</code> 失败时 errno 可能是 <code>EACCES</code> 或 <code>ENOENT</code>（proc 未挂载）</li>
<li>Windows 下若 <code>GetCommandLineW</code> 返回空指针，大概率处于受限执行上下文，此时只能退回到 <code>argv</code>（尽管不原始）</li>
<li>不要假设“本地开发能跑就线上没问题”，容器镜像里 procfs 权限经常被静默收紧</li>
</ul>
<p>获取原始命令行这事，表面只是读个字符串，实际牵扯到 OS 内核接口、运行时初始化顺序、容器隔离策略三层差异。最易被忽略的是：Linux 的 <code>/proc/self/cmdline</code> 在 chroot 或 PID namespace 中依然有效，但若容器 runtime 显式 remount proc 且过滤了 cmdline —— 那连 <code>open</code> 都会直接失败，连 errno 都未必能拿到。</p></char>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
