systemd --scope 是最轻量的运行时环境隔离手段，无需改服务配置或依赖容器，通过绑定进程到独立 cgroup 实现 CPU、内存、IO 限制并自动清理。
用 systemd --scope 快速隔离进程资源
不需要改服务配置、不依赖容器，systemd --scope 是最轻量的运行时环境隔离手段。它把一组进程绑定到独立的 cgroup 下，能限制 CPU、内存、IO，且自动清理——进程退出后 cgroup 自动销毁。
- 适合临时跑测试脚本、并行执行多个同名服务（如不同端口的
python app.py） - 必须用 root 或有
org.freedesktop.systemd1.manage-units权限的用户执行 - 内存限制需内核开启
cgroup_memory（现代发行版默认开启），检查：cat /proc/cgroups | grep memory - 别直接在 shell 中后台运行（
&），否则会脱离 scope；要用--scope包裹整个命令链
sudo systemd-run --scope -p MemoryMax=512M -p CPUQuota=50% --scope python3 server.py --port 8001
用 unshare 实现文件系统与网络命名空间隔离
unshare 不依赖 systemd，适合无特权容器化场景（如 CI 环境中普通用户需要隔离 /tmp 或 /etc/hosts）。但它默认不设资源限制，仅提供命名空间隔离，需配合 cgexec 或手动挂载 cgroup 才能控 CPU/内存。
- 常见错误：只用
unshare -r做 user namespace，却没映射 UID/GID，导致ls /proc报错 “Permission denied” - 网络隔离要加
--net并手动配置 veth + iptables，否则新 netns 默认无网络 - 挂载隔离（
--mount）必须搭配--user或先mount --make-rprivate /，否则会提示 “Operation not permitted”
unshare --user --pid --mount --fork --root=/tmp/myroot chroot /tmp/myroot /bin/sh
避免误用 chroot 当作完整隔离方案
chroot 只改变根目录路径，不隔离进程、网络、用户、cgroup —— 它不是安全边界，更不是容器替代品。生产环境若仅靠 chroot 隔离多业务，极易发生 PID 冲突、端口抢占、日志混写等问题。
- 无法防止子进程逃逸：只要进程有
cap_sys_chroot或 root 权限，chroot可被chroot("..")绕过 - 所有业务仍共享同一内核调度器，一个业务夯住 CPU，其他全卡死
-
/dev、/proc、/sys若未手动 bind-mount，很多程序（如ps、systemctl）直接失效 - 真正需要的是组合：比如
chroot + unshare --user + cgexec -g memory:/myapp
选型关键：看业务是否需要跨主机迁移或强安全边界
如果只是同一台机器上跑多个 Python/Node.js 服务，互不干扰即可，systemd --scope 足够；如果要防恶意代码读宿主文件或建反向连接，就必须上 podman run --isolation=chroot 或 docker run --read-only --tmpfs；若连内核模块都不能信（比如多租户 SaaS），就得考虑 KVM 虚拟机级隔离。
- 别为“看起来高级”选 Docker：纯本地 CLI 工具链并行运行，
systemd-run启动快、无镜像体积、日志直通 journal - Podman 的
--isolation=chroot模式其实仍用unshare，但自动处理了 /dev 和 /proc 挂载，比手写unshare更稳 - 所有方案都绕不开 cgroup v2 —— 如果
/sys/fs/cgroup/cgroup.controllers为空，说明系统还在用 v1，部分限制（如 memory.high）不可用
MemoryMax 在 cgroup v1 下是无效字段，而 unshare --mount 在默认 mount propagation 为 shared 的系统上会失败。 
