macOS 多用户自动化服务：让服务在无人登录时也能拥有 GUI
前言
在 macOS 上部署多用户服务，说实话挺有意思的。需求很明确：一台 Mac Mini，上面跑着 10 个 iMessage 服务实例，每个实例对应一个独立的 macOS 用户（user-1, user-2…）。
听起来不难对吧？但真正动手才发现，最大的挑战不是技术实现本身，而是如何让这些服务在重启后、无人登录的情况下，依然能拥有完整的 GUI 上下文（WindowServer）。这篇文章想跟你聊聊我们是怎么一步步 debug，最终找到解决方案的。
1. 问题的本质：既要 GUI，又不想登录
我们遇到的核心矛盾其实挺简单，但也挺棘手：
首先是硬性依赖。iMessage 服务强依赖 imagent 进程，而这个进程必须在用户的 GUI 会话（WindowServer Session） 中运行才能正常收发消息。如果只是用 sudo -u user 启动进程，服务是“哑”的——看起来在跑，其实啥也干不了。
其次是运维现实。如果每次重启都需要管理员手动去登录这 10 个账号，不仅繁琐，而且根本无法实现无人值守的自动化。想象一下，机器放在机房，每次重启都得派人去点击 10 次登录界面，这实在太不现实了。
我们想要的效果很简单：机器一通电，所有用户的 iMessage 服务全部自动上线，不需要任何人去点击登录界面。就这么简单的需求，却花了我们不少时间才搞定。
2. 第一轮尝试：为什么常规方案都走不通？
macOS 的设计初衷是单用户或少用户交互系统，不是服务器。所以当我们需要多用户自动化服务时，系统本身其实没有提供太多现成的方案。
2.1 尝试过的“死胡同”
一开始，我们试了各种常规方案，但全都碰壁了：
LaunchDaemon：第一个想到的自然是 LaunchDaemon，它可以开机自启，权限也够高。但问题是，它运行在 system context，没有 GUI。服务是起来了，但发不出消息。
LaunchAgent：这个就是为 GUI 程序设计的，看起来很符合我们的需求。但它有个致命问题：必须用户登录后才加载。这就形成了一个死循环——你不登录，它不启动；你想启动，必须登录。
自动登录（Auto Login）：macOS 确实提供了自动登录功能，但只能设置一个用户自动登录。我们有 10 个用户，顾得了一个顾不了其他九个。
Fast User Switching：快速用户切换听起来挺好，但依然依赖人工在锁屏界面操作，解决不了自动化的需求。
试了一圈下来，我们发现一个核心问题：**在 macOS 上，没有登录，就没有 GUI；没有 GUI，iMessage 就废了。**这是系统设计层面的限制，不是我们能轻易绕过的。
3. 破局的灵感：VNC 远程桌面
既然正常途径走不通，我们开始琢磨有没有什么“旁门左道”可以绕过去。
有一天在调试时，我们偶然发现了一个有意思的现象：当用 VNC 远程连接到某个用户时，macOS 会为这个用户创建或激活一个 GUI 会话。更重要的是，即便物理显示器停留在锁屏界面，后台的 VNC 会话依然拥有完整的 WindowServer 上下文。
这让我们眼前一亮：如果能写个脚本，模拟 VNC 客户端去连接这 10 个用户，不就等于“激活”了他们的 GUI 会话吗？
虽然听起来有点投机取巧，但这确实是一个可行的思路。接下来的问题就是如何实现了。
4. 技术实现：Fast Login 方案
我们把这个方案称为 Fast Login，核心思路是自动化整个 VNC 连接过程。具体怎么做呢？让我慢慢道来。
4.1 第一步：搭建“大本营”
虽然我们不能让 10 个子用户自动登录，但可以让 1 个管理员用户（Admin）自动登录。Admin 登录后，我们就有了一个可以在 GUI 环境下运行脚本的“大本营”。
这一步其实很简单，在系统设置里配置好自动登录就行了。但这只是基础，接下来才是关键。
4.2 第二步：建立 SSH 隧道
macOS 的 VNC 服务默认监听 5900 端口。当我们需要并发连接 10 个用户时，端口冲突就成了一个大问题——你不可能让 10 个用户都监听同一个端口对吧？
解决办法是用 SSH 本地端口转发。我们在 Admin 用户下建立 10 个 SSH 隧道，每个隧道映射到不同的本地端口：
# 在 Admin 用户下运行
ssh -L 5901:localhost:5900 user-1@localhost -N &
ssh -L 5902:localhost:5900 user-2@localhost -N &
ssh -L 5903:localhost:5900 user-3@localhost -N &
# ... 以此类推这样一来：
- 连接
localhost:5901实际上连的是user-1的 VNC - 连接
localhost:5902实际上连的是user-2的 VNC - 其他用户以此类推
SSH 隧道建好后，我们就有了 10 个独立的“通道”，可以分别连接到每个用户的 VNC 服务。
4.3 第三步：用 AppleScript 模拟登录
通道建好了，接下来需要“人”去连接。这里我们用 AppleScript 来控制 macOS 自带的 Screen Sharing 应用。
tell application "Screen Sharing"
open location "vnc://localhost:5901" # 连接 user-1
end tell
# 等待连接窗口出现
delay 1
# 模拟键盘输入密码
tell application "System Events"
keystroke "password"
keystroke return
end tell
# 等待登录成功
delay 2
# 关闭窗口（但会话保持活跃）
tell application "Screen Sharing"
quit
end tell脚本运行的一瞬间，你会看到屏幕上弹出一个 VNC 窗口，显示 user-1 的桌面——Bingo！GUI 会话激活了！
然后脚本立即关闭窗口，但神奇的是，后台的 GUI 会话依然保持活跃。这就是我们想要的效果。
把这个过程循环 10 次，分别连接 user-1 到 user-10，整个激活过程大概只需要 20-30 秒。
5. Debug 之旅：一个又一个的坑
原理说起来挺简单，但真正落地时，我们遇到了各种各样的问题。这里记录几个典型的坑和解决办法。
5.1 坑 1：权限拦截（Preflight）
第一个大坑是权限问题。我们的服务启动涉及到进程注入，而 macOS 的 SIP（System Integrity Protection）和 AMFI（Apple Mobile File Integrity）会直接拦截这些操作。
一开始我们完全没意识到这个问题，服务怎么都启动不了，日志里只有一堆神秘的权限错误。查了好久才发现，必须在 Recovery 模式下禁用 SIP，并配置 boot-args 来禁用 AMFI 的特定检查（比如 amfi_get_out_of_my_way=1）。
为了让部署更简单，我们专门做了一个 Preflight 程序，自动检查这些参数。如果检测到配置不对，程序会提示用户，甚至可以自动重启到 Recovery 模式。这样就避免了每次部署都要手动检查一遍的麻烦。
5.2 坑 2：LaunchAgent 的“鸡生蛋”问题
我们需要在每个子用户里跑一个 Keepalive 脚本来保活服务。这个脚本是 LaunchAgent，理论上应该在用户登录后自动加载。但问题来了：我们的“登录”是通过 VNC 模拟的，系统不一定会自动加载所有的 LaunchAgent。
这就形成了一个“鸡生蛋”的问题：我们需要 GUI 会话来加载 LaunchAgent，但 LaunchAgent 本身又是为了维持 GUI 会话而存在的。
解决办法是在 Fast Login 脚本成功激活用户 GUI 后，从 Admin 侧强制帮子用户加载他们的 LaunchAgent：
# 获取用户的 UID
uid=$(id -u user-1)
# 强制加载该用户的 LaunchAgent
sudo launchctl bootstrap gui/$uid ~/Library/LaunchAgents/com.example.keepalive.plist这个命令需要 root 权限，但可以跨用户加载 LaunchAgent。虽然有点 hacky，但确实管用。
5.3 坑 3：静默断连
即使激活了 GUI 会话，如果长期没有操作，iMessage 的 imagent 进程还是会挂起或者进入休眠状态。消息发不出去，收也收不到。
我们最初以为只要 GUI 会话在，服务就会一直跑。但后来发现，macOS 对“没有用户交互”的会话有一套自己的休眠机制，时间一长就会自动断连。
解决办法是做一个 Keepalive 服务，每 10 分钟运行一次，通过 AppleScript 发送一个无意义的 XPC 请求给 imagent：
tell application "Messages"
# 只是触发一下，不实际发送任何消息
get every service
end tell这个操作不会产生任何实际效果，但足以让系统认为“用户还在活跃”，从而防止 GUI 会话进入深度休眠。
6. 一些思考
回头看这个项目，其实挺有意思的。我们一开始以为只是个简单的部署任务，结果发现 macOS 的设计理念和服务器场景有很大的不同。
这也让我意识到，做技术方案时，理解系统的设计哲学特别重要。macOS 设计之初就不是为多用户服务器场景专门设计的，所以当我们想要突破这个限制时，自然会遇到各种问题。
但好在，通过一些“投机取巧”的方法（比如用 VNC 模拟登录），我们还是找到了解决方案。虽然不算特别优雅，但确实能用，而且相当稳定。
这套 SSH 隧道 + VNC 回环 + AppleScript 自动化 的组合拳，成功帮我们攻克了 macOS “零登录激活多用户 GUI” 这个技术难题。如果你也遇到类似的需求，希望这篇文章能给你一些启发。