把 C++ 程序部署到 CentOS，表面上看只是上传一个可执行文件，真正决定能不能稳定运行的，往往是编译器版本、动态库依赖和服务管理方式。下面按实际部署顺序拆开讲：先准备编译环境，再处理构建与依赖，最后把程序放到服务器上运行，并用 systemd 接管，方便后续维护和重启自启。
准备 CentOS 编译环境
如果你打算直接在 CentOS 上编译 C++ 项目，第一步是把基础工具链装齐，包括 GCC/G++、常用开发工具和 CMake。
sudo yum update -y
sudo yum groupinstall -y "Development Tools"
sudo yum install -y cmake
这组命令适合大多数常规项目。如果项目要求更新版本的 GCC，例如 10.x，可以通过 Software Collections（SCL）安装，不会覆盖系统自带编译器：
sudo yum install -y centos-release-scl
sudo yum install -y devtoolset-10-gcc-c++
scl enable devtoolset-10 bash
这里有一个容易忽略的点：scl enable 只对当前 shell 会话生效。如果你希望后续登录后默认使用这套工具链，需要把相关命令写入 ~/.bashrc。
编译 C++ 程序
项目怎么编译，取决于代码规模和依赖复杂度。单文件程序可以直接用 g++，多文件项目则更适合交给 CMake 管理。
单文件程序：直接用 g++
如果只有一个源文件，最直接的方式就是：
g++ -o myapp main.cpp
生成的 myapp 如果没有额外依赖，通常可以直接复制到服务器执行。
多文件项目：用 CMake 管理构建
当项目包含多个源文件，或者依赖 OpenSSL、Boost 这类库时，建议使用 CMake 来统一管理构建流程。
先在项目根目录准备 CMakeLists.txt：
cmake_minimum_required(VERSION 3.10)
project(MyApp)
add_executable(MyApp main.cpp lib.cpp)
find_package(OpenSSL REQUIRED)
target_link_libraries(MyApp PRIVATE OpenSSL::SSL OpenSSL::Crypto)
然后创建构建目录并执行编译：
mkdir build && cd build
cmake ..
make
编译完成后，可执行文件 MyApp 会出现在 build 目录。对于稍复杂的项目，这种方式比手写长命令更容易维护，也更方便以后切换依赖和编译参数。
部署前先处理依赖库
C++ 程序部署时最常见的问题，不是代码本身，而是服务器上缺少运行时库。依赖通常分为两类：系统库，例如 glibc；第三方库，例如 Boost、OpenSSL。
系统库与开发包安装
系统库通常可以直接通过 yum 安装对应包。以 OpenSSL 为例：
sudo yum install -y openssl-devel
原文给出的做法是安装 -devel 包，这在编译阶段尤其常见。实际部署时，也要确认目标机器具备对应运行时库。
第三方库常见处理方式
第三方依赖一般有几种来源：
- 直接用
yum安装现成包，例如boost-devel； - 通过 CMake 的
find_package自动查找； - 使用
vcpkg这类跨平台包管理器； - 手动下载源码编译，并安装到
/usr/local/lib等目录。
无论采用哪种方式，部署前都建议执行一次动态库检查：
ldd myapp
如果输出中出现 not found，说明某个动态库没有被正确找到。此时可以先临时设置库搜索路径：
export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH
这一步非常关键。很多“本地能跑、服务器一启动就报错”的问题，最后都落在这里。
上传到服务器并启动程序
确认程序编译完成、依赖也齐全后，就可以把可执行文件传到目标服务器。
用 scp 上传二进制文件
scp myapp user@server_ip:/opt/myapp
上传后登录服务器，进入部署目录并补上执行权限：
ssh user@server_ip
cd /opt/myapp
chmod +x myapp
手动运行与库路径设置
先直接执行，确认程序本身能启动：
./myapp
如果依赖库不在系统默认搜索路径，需要先设置 LD_LIBRARY_PATH：
export LD_LIBRARY_PATH=/opt/myapp/libs:$LD_LIBRARY_PATH
./myapp
如果这条环境变量每次都需要手动设置，可以把 export 写入 ~/.bashrc 或 /etc/profile，减少重复操作。
生产环境建议接入 systemd
如果程序只是临时验证，手动运行已经够用；但只要进入生产环境，通常都建议交给 systemd 管理。这样可以获得开机自启、异常重启和统一状态查看能力。
创建服务文件
先创建服务配置：
sudo nano /etc/systemd/system/myapp.service
写入如下内容，路径、用户和用户组按实际环境调整：
[Unit]
Description=My C++ Application
After=network.target
[Service]
User=myuser
Group=mygroup
ExecStart=/opt/myapp/myapp
Restart=always
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
[Install]
WantedBy=multi-user.target
加载并启用服务
sudo systemctl daemon-reload
sudo systemctl start myapp
sudo systemctl enable myapp
完成后，可以用下面的命令查看服务状态：
systemctl status myapp
对线上服务来说，systemd 的价值不只是“能启动”，而是把运行、重启和状态查询纳入统一管理，后续排障会轻松很多。
安全与维护的几个实用建议
程序上线后，部署工作并没有结束。下面这些细节，往往决定后续维护成本。
安全加固
- 关闭不必要的端口，使用
firewalld限制访问范围； - 避免直接用 root 运行程序，单独创建普通用户，通过
sudo提权处理管理操作。
日志查看与输出管理
如果是手动启动程序，可以把输出重定向到日志文件：
./myapp > myapp.log 2>&1 &
如果已经交给 systemd 管理，则可以直接查看：
journalctl -u myapp
备份、监控与依赖更新
- 定期备份代码和业务数据；
- 使用
top、htop观察 CPU、内存等资源占用； - 及时更新依赖库，修补已知安全漏洞。
如果把这几项也纳入日常流程，CentOS 上的 C++ 服务基本就能从“能跑”进入“可持续维护”的状态。
