systemd模板单元通过@.service文件和%i变量实现多实例管理，启动时指定实例名即可自动适配路径、参数等；需正确命名、重载配置并用systemctl start myapp@inst启动。
用 systemd 模板单元管理多实例服务，核心就是写一个带 @ 的服务文件，再用 %i 动态注入实例名。它不是“复制多个 service 文件”的土办法，而是靠一套配置驱动所有实例，启动时指定名字就能自动适配路径、参数、日志、用户权限等。
创建模板服务文件
在 /etc/systemd/system/ 下新建一个以 @ 结尾的文件，比如 myapp@.service。注意结尾必须是 @.service，不能漏掉点号或写成 @.service.txt。
-
%i表示你启动时传入的实例名，如myapp@prod中的prod -
%n是完整单元名，如myapp@prod.service，适合用于日志路径或描述中 - 避免在
ExecStart里拼接复杂命令；参数多时建议通过环境变量或配置文件传递，更清晰也更安全
在服务定义中使用 %i
模板文件里可把 %i 当作变量，嵌入到任意支持的位置：
-
Description=MyApp instance %i—— 启动后systemctl status显示更直观 -
WorkingDirectory=/opt/myapp/instances/%i—— 每个实例工作目录隔离 -
ExecStart=/usr/bin/python3 /opt/myapp/main.py --env=%i—— 把实例名作为运行时参数传给程序 -
StandardOutput=journal和StandardError=journal已足够；如需落盘日志，可用SyslogIdentifier=myapp-%i区分不同实例日志流
启用并启动具体实例
模板文件本身不能直接启动，必须带上实例名：
- 启动：
sudo systemctl start myapp@staging.service - 开机自启：
sudo systemctl enable myapp@staging.service - 查看状态：
systemctl status myapp@staging（后缀.service可省略） - 查日志：
journalctl -u myapp@staging -n 50或按标识过滤：journalctl SYSLOG_IDENTIFIER=myapp-staging
验证与调试要点
服务起不来时，别急着翻应用日志，先确认 systemd 是否加载了你的模板：
- 检查是否识别：
systemctl list-unit-files | grep myapp@—— 应看到myapp@.service显示为enabled或disabled - 确认加载路径：
systemctl show myapp@prod --property=FragmentPath—— 确保读的是/etc/systemd/system/myapp@.service而非系统默认位置 - 重载配置：
sudo systemctl daemon-reload每次改完模板文件后都必须执行 - 若提示 “unit not found”，大概率是文件名写错、后缀不对，或没放到
/etc/systemd/system/
