在 CentOS 上跑通一个 C++ 程序，难点通常不在“把代码编译出来”，而在于怎样把编译、调试、性能测试和上线准备串成一条清晰流程。下面按实际操作顺序梳理一遍：先解决编译环境，再验证程序能否正确运行，最后再看生产部署时最容易出问题的依赖、日志、权限和监控。

准备编译环境

CentOS 默认环境里，未必已经装好 g++。如果系统还没有 C++ 编译器，可以先安装 gcc-c++：

sudo yum install gcc-c++

这一步完成后，就具备了基本的 C++ 编译能力。源代码文件通常保存为 .cpp，编辑器可以继续使用自己熟悉的工具，例如 vim 或 nano。

编译并运行程序

代码写好后，先切到源文件所在目录，再用 g++ 进行编译。示例文件名如果是 main.cpp，可执行文件名希望输出为 myprogram，命令如下：

g++ -o myprogram main.cpp

这条命令会生成一个名为 myprogram 的可执行文件。编译成功后，直接运行即可：

./myprogram

这一阶段主要看两件事：一是程序能不能正常启动，二是输出和预期是否一致。如果这里就出现异常，后面的部署工作最好先暂停，优先把基础功能跑通。

调试错误并做基础性能测试

用 gdb 定位运行问题

如果程序能编译，但运行结果不对，或者执行中途崩溃，就需要进入调试阶段。CentOS 上最常见的工具是 gdb：

gdb myprogram

进入 gdb 后，可以在提示符下执行运行、暂停、查看变量等调试操作，逐步定位问题发生的位置。对于刚完成编译的程序来说，这一步的目标不是“把所有问题一次找完”，而是先确认错误究竟出在输入、逻辑还是运行时状态上。

用 time 看程序耗时

功能正确后，还可以顺手做一次基础性能测试。最简单的方式就是使用 time：

time ./myprogram

输出里通常会看到三项时间信息：

• real：程序实际消耗的总时间
• user：用户态执行所耗费的 CPU 时间
• sys：内核态执行所耗费的 CPU 时间

这组数据不能直接替代完整压测，但足够帮助你先判断程序是否存在明显的性能瓶颈，尤其适合在部署前做第一轮对比。

部署到生产环境时要重点检查什么

依赖、配置与进程管理

当程序在测试环境中已经可以稳定运行，接下来才适合进入生产部署。这个阶段要重点确认依赖库是否齐全、配置文件如何管理，以及服务怎样启动和停止。

如果程序需要长期驻留运行，通常还要借助 systemd 之类的工具做进程管理，保证服务能按预期启动、退出和重启，而不是只依赖手工执行命令。

日志机制不能缺位

生产环境里的问题，很多都不是当场就能复现的，所以日志非常关键。至少要保证两件事：程序能输出足够有用的运行信息，日志文件也能被正确管理和轮转。否则一旦出现故障，排查时往往缺少最基本的依据。

权限与安全边界要提前设好

上线时还要检查程序的运行身份，以及相关文件和网络权限是否配置正确。程序应以合适的用户身份运行，避免权限过大带来风险，也要防止权限不足导致读写失败、端口无法绑定等问题。

监控和报警决定故障响应速度

最后别忽略监控和报警。上线后的重点已经不再是“程序能不能启动”，而是“程序出问题时能不能尽快发现”。为运行状态建立监控，并在异常发生时及时报警，才能把故障处理从被动排查变成主动响应。

上线前的最后一步：在相似环境完整跑一遍

无论流程看起来多顺，正式进入生产环境前，都应该先在与生产尽可能接近的测试环境中完整走一遍。从安装依赖、编译运行，到调试、性能观察、日志检查、权限校验、监控接入，最好都实际执行一次。这样做的价值，是把“理论可行”变成“流程确认可落地”，尽量把问题留在上线前解决。