关键在于确保python服务稳定运行：execstart用绝对路径调用虚拟环境python解释器，显式配置workingdirectory和environment（含path、pythonunbuffered等），type=simple为默认安全选择，restart=on-failure需搭配restartsec和startlimitintervalsec防重启风暴，user/group权限须匹配路径实际读写需求。
直接用 systemd 守护 Python 后台进程，关键不是“让它跑起来”，而是“让它不悄无声息地死掉、重启时不缺席、出错时有迹可循”。绝大多数失败都卡在 ExecStart 路径写错、环境变量没继承、或用户权限不对这三处。
ExecStart 必须用绝对路径调用虚拟环境里的 Python 解释器
别写 source venv/bin/activate && python app.py——systemd 默认用 /bin/sh（通常是 dash），不认识 source，也不加载 bash 的 profile。这条命令会直接报错退出，journalctl -u myapp.service 里只显示 Failed to execute command 或空行。
正确做法是绕过 shell 激活环节，直击解释器本身：
ExecStart=/opt/myapp/venv/bin/python /opt/myapp/app.pyExecStart=/home/user/miniconda3/envs/api/bin/python /home/user/api/main.py
这样启动的进程天然绑定该环境的所有包和二进制依赖，无需激活，也和 shell 类型无关。
WorkingDirectory 和 Environment 缺一不可
不设 WorkingDirectory，脚本里用 open("config.yaml") 或 logging.FileHandler("log.txt") 就会报 No such file or directory；不显式声明 Environment，pipenv、poetry 或 conda 环境里的工具可能根本找不到，报 ModuleNotFoundError 或直接 exec format error。
必须显式配置这两项：
-
WorkingDirectory=/opt/myapp（设成项目根目录，不是脚本所在子目录） Environment="PATH=/opt/myapp/venv/bin:/usr/local/bin:/usr/bin:/bin"-
Environment="PYTHONUNBUFFERED=1"（避免日志被缓冲，实时可见）
如果项目结构依赖 PYTHONPATH（比如 src/ 下放模块），还得加：Environment="PYTHONPATH=/opt/myapp/src"。
Type=simple 是默认安全选择，Type=notify 别乱配
绝大多数纯 Python 脚本（含 while True:、asyncio.run()、uvicorn.run()）都是前台阻塞运行，Type=simple 最稳妥。若误配 Type=notify，而脚本又没调用 sd_notify()，systemd 会等超时（默认 90 秒）后强行杀掉进程，并在 systemctl status 里显示 Failed with result 'timeout'。
只有以下情况才用 Type=notify：
- 你用了
gunicorn、uvicorn --reload=false、hypercorn等支持 systemd notify 的服务器 - 你自己在代码里调用了
systemd.daemon.notify("READY=1")
不确定？先用 Type=simple，看 systemctl is-active myapp 是否稳定返回 active。
Restart=on-failure 必须搭配 RestartSec 和 StartLimitIntervalSec
只写 Restart=on-failure 很危险：脚本一崩溃，systemd 可能在 1 秒内反复拉起又失败，触发默认限流（10 次/10 秒），之后直接停服并标记为 start-limit-hit，systemctl status 里能看到明确提示。
生产环境应这样控制节奏：
-
Restart=on-failure（上线前务必改回这个，always会掩盖真实错误） -
RestartSec=5（每次重启前等 5 秒，给数据库/网络恢复留时间） -
StartLimitIntervalSec=600（10 分钟窗口） -
StartLimitBurst=5（最多允许重启 5 次）
调试阶段可临时加 Restart=always，但上线前必须换回来——否则一个永久性错误（比如配置文件缺失）会让服务陷入无限重启循环，还查不到根因。
最容易被忽略的是 User 和 Group 对路径的实际读写权限。即使 systemd 配置全对，只要该用户对 WorkingDirectory、日志目录、虚拟环境目录没有读/执行（目录）或写（日志）权限，服务照样静默失败。验证前，先 sudo -u youruser ls -l /opt/myapp 看一眼。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
