Iris项目部署只需传输静态编译的二进制文件并配置systemd服务；无需Go环境、外部依赖或运行时，编译时须设CGO_ENABLED=0确保静态链接，service文件中必须指定User和WorkingDirectory以保障权限与路径正确。
直接结论：Iris 项目部署到 Linux 就是传一个二进制文件 + 配一个 systemd 服务，不需要 Go 环境、不装依赖、不配 runtime。 它和 Node.js 或 .NET 的部署逻辑完全不同——Go 编译出的 myapp 是自包含的，只要目标系统是兼容架构（如 linux/amd64），扔上去就能跑。
本地编译时必须关掉 CGO
Go 默认启用 cgo，它会让程序动态链接系统 libc，导致在低版本 glibc 的服务器上启动失败（报错类似 version `GLIBC_2.34' not found）。所以编译命令里一定要加 CGO_ENABLED=0：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o myapp ./main.go
- 如果 Iris 代码里用了
net.Resolver（比如自定义 DNS 查询）、sqlite3或其他 C 依赖，就得设CGO_ENABLED=1，但必须确保目标服务器的glibc版本 ≥ 编译机； - 用
file myapp检查是否静态链接：输出含statically linked才算成功； - 别用
go run或本地开发端口直接上传——那只是临时调试，不是部署。
systemd 服务配置不能漏掉 User 和 WorkingDirectory
很多人照抄模板只改 ExecStart，结果日志里反复报 permission denied 或找不到配置文件。Iris 启动时默认从当前目录读 iris.yml 或加载环境变量，所以必须明确指定运行用户和工作路径：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
[Unit] Description=Iris API Service After=network.target [Service] Type=simple User=www-data WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/myapp --port=8080 Restart=always RestartSec=5 Environment=GIN_MODE=release [Install] WantedBy=multi-user.target
-
User=www-data是关键：避免用root运行，也别留空（默认继承调用者权限，systemd 可能以root启动但子进程权限混乱）； -
WorkingDirectory必须和ExecStart中二进制所在路径一致，否则./config.json这类相对路径会失效； -
Environment可传 Iris 支持的变量，比如IRIS_ENV=production，但注意 Iris 本身不读GIN_MODE，那是 Gin 的遗留项，实际无效。
启动后看不到日志？先查 journalctl 再动 supervisor
Iris 不自带日志轮转或文件输出，所有 stdout/stderr 默认由 systemd 拦截。别急着装 supervisor 或改代码加日志文件——先用原生方式确认是否真在跑：
- 执行
sudo systemctl status myapp，看Active:是否为active (running)； - 查实时日志：
sudo journalctl -u myapp -f，这是最准的启动反馈； - 如果显示
failed to start且没具体错误，十有八九是端口被占（bind: address already in use）或User权限不足（比如试图监听 80 端口但没 cap_net_bind_service）； - Supervisor 在 Iris 场景下纯属冗余——systemd 已完整覆盖守护、重启、日志、开机自启，额外套一层反而增加故障点。
真正容易被忽略的是权限链：Iris 进程以 www-data 身份运行，但它要读的配置文件、写的上传目录、连的数据库 socket 文件，都得对这个用户可读/可写。别只盯着服务配置，忘了检查 /opt/myapp/config.yml 的 ls -l 输出。
