在Linux和macOS平台，获取启动参数最普遍且推荐的方式是在main函数中直接接收int argc和char* argv[]。argc表示参数个数（包含程序名），argv是以nullptr结尾的C字符串指针数组，其中argv[0]通常是可执行文件的路径。而在Windows平台上，则需要采用不同的方法——通过GetCommandLineW配合CommandLineToArgvW来获取宽字符参数。

Linux/macOS 下使用 argv 和 argc 获取启动参数

main 函数的两个参数是检索命令行参数最直接且符合标准的方式：int argc 表示参数数量，char* argv[] 是以 nullptr 结尾的 C 字符串指针数组。每个 argv[i] 指向一个具体的参数字符串，argv[0] 通常是可执行文件路径，可能包含相对路径或符号链接目标，并非一定是绝对路径。

需要明确的是：这并不是你去主动“获取”参数，而是系统在进程启动时已将参数准备就绪，你只需在 main 中接收即可。如果在其他函数中也需要使用这些参数，建议提前将其存储到全局变量或静态对象中，例如：

static std::vector g_args;
int main(int argc, char* argv[]) {
    for (int i = 0; i < argc; ++i) {
        g_args.emplace_back(argv[i]);
    }
    // 后续任意位置可用 g_args
}

切勿尝试在 main 函数之外调用 getauxval 或读取 /proc/self/cmdline 来重新获取参数——这完全没有必要，且容易引发错误。

Windows 下不要仅依赖 argv，应使用 GetCommandLineW + CommandLineToArgvW

Windows 的处理方式有所不同。尽管其 argv 在宽字符编译（定义了 UNICODE）下为 wchar_t*，但解析行为与 POSIX 不一致：原始命令行中的引号、空格等细节不会被保留，非 ASCII 字符的处理依赖于当前代码页（ANSI 版本），而且早期 Visual Studio 版本可能出现 CRT 截断问题。更可靠的方法是直接调用 Win32 API：

• GetCommandLineW() 返回完整的原始宽字符串，包含程序名和所有参数，尚未分割
• CommandLineToArgvW(cmdline, &argc) 按照 Windows 规则进行解析，支持转义字符、嵌套引号等，返回 wchar_t** 数组

关键点：返回的 wchar_t** 必须使用 LocalFree 释放，不能使用 delete[] 或 free；argc 包含 argv[0]，即程序名。

wchar_t* cmd = GetCommandLineW();
int argc_w;
wchar_t** argv_w = CommandLineToArgvW(cmd, &argc_w);
if (argv_w != nullptr) {
    // 使用 argv_w[0] 到 argv_w[argc_w-1]
    LocalFree(argv_w); // 必须调用！
}

跨平台封装时，避免使用 std::system 或 std::getenv 读取启动参数

std::system 用于执行新进程，与当前进程参数无关；std::getenv 读取的是环境变量，而非命令行参数。有人误以为 /proc/self/cmdline（Linux）或 NSProcessInfo.processInfo().arguments（macOS）可以补充 argv，但实际上完全没必要——argv 才是权威来源。除非你正在编写注入型工具或调试器，否则不要绕过 main 参数。

真正需要跨平台抽象时，推荐只做一层薄包装：

• Linux/macOS：直接转发 argc 和 argv 即可
• Windows：在 main 或 wmain 中调用 CommandLineToArgvW，统一转换为 std::vector 或 std::vector

不要尝试使用 dlopen + dladdr 或 backtrace 反推参数——这种方法不可靠，且会破坏启动语义。

argv 的生命周期与修改风险

argv 指向的内存由运行时在栈或堆上分配，生命周期与进程相同，且是可写的。POSIX 允许修改 argv[0] 以改变进程名显示，例如在 Linux 上配合 prctl(PR_SET_NAME, ...) 使用。不过需要注意以下几点：

• 修改 argv[i] 的内容本身是安全的（只要不越界），但修改后不能再调用 exec 系列函数，因为这些函数会重新初始化 argv
• 某些容器或沙箱环境（如 gVisor、Firecracker）可能会限制对 argv 内存的写权限
• ASLR 不影响 argv 地址的稳定性，但不同的启动方式（如 fork+exec 与直接加载）可能导致 argv 分配位置有所不同

有一点容易被忽略：如果你使用 std::string 保存 argv[i]，需要确保 argv 所指的内存未被提前释放。实际上这块内存仅在 main 返回后才会失效，因此只要不在线程中进行异步延迟访问，通常不会出现问题。