systemctl start 返回 0 服务却 failed:一次 Linux systemd Type 配置排查复盘

2024 年,我把一个服务交给 systemd 托管,结果碰上一件特别拧巴的事:我敲 systemctl start myapp,命令安安静静地返回了,没有任何报错,退出码是 0——在我看来,这就是"启动成功"。可我去访问这个服务,连不上。我以为是启动慢,等了一会儿再访问,还是连不上。我 systemctl status myapp 一看,傻了:状态是 failed。一个我刚刚"成功启动"、命令明明白白返回 0 的服务,转头就告诉我它 failed 了。更怪的是,我直接在命令行里手动跑这个程序的启动命令,它跑得好好的,服务稳稳当当——可一旦交给 systemd 来 start,它就活不过几秒。我一度怀疑是 systemd 和这个程序"八字不合"。我把启动命令、环境变量、工作目录,一项一项和手动跑的时候比对,全都一模一样。手动能跑,systemd 跑不了,而两边的命令、环境又完全相同——这个矛盾把我困了很久。最后我才想明白:问题根本不在"启动命令"上。systemctl start 那个让我安心的返回 0,它的含义,和我以为的"服务起来了",根本就是两回事;而 systemd 转头就判它 failed,也不是 systemd 出了 bug——是我从一开始,就没跟 systemd 说清楚,我这个服务,到底是【怎样一种】服务。这件事逼着我把 systemd 的 Type=、服务生命周期、journalctl 这一整套彻底理清了。本文复盘这次实战。

问题背景

环境:CentOS 7,systemd,一个会"自己转入后台"的老式服务
事故现象:
- systemctl start myapp 返回 0,没有任何报错
- ★ 但 systemctl status 立刻显示 failed,服务连不上
- ★ 同样的启动命令,在命令行手动跑,服务好好的

现场排查:
# 1. start 返回 0,看着像成功了
$ systemctl start myapp
$ echo $?
0                                        # ★ 退出码 0 —— 但这不代表服务活着

# 2. ★ status 一看:failed
$ systemctl status myapp
   Loaded: loaded (/etc/systemd/system/myapp.service)
   Active: failed (Result: exit-code)     # ★ 已经 failed
  Process: 9001 ExecStart=/opt/myapp/start.sh (code=exited, status=0)
   Main PID: 9001 (code=exited, status=0/SUCCESS)
# ★ 注意:Main PID 9001 exited,status=0 —— 它"正常退出"了,
#   可 systemd 还是判 failed。为什么?

# 3. ★ 看这个服务的 unit 文件
$ cat /etc/systemd/system/myapp.service
[Service]
ExecStart=/opt/myapp/start.sh
# ★ 没写 Type= —— 用的是默认值 Type=simple

# 4. ★ 看 start.sh 干了什么
$ cat /opt/myapp/start.sh
#!/bin/bash
/opt/myapp/bin/myapp --daemon &          # ★ 关键:--daemon,程序自己转入后台
# 脚本启动程序后,自己立刻就 exit 了

# 5. ★ 手动跑能行,因为没人盯着那个 exit
$ /opt/myapp/start.sh ; echo "脚本结束了,但 myapp 还在后台跑"
# ★ 手动跑时,脚本结束了我不在乎,后台的 myapp 活得好好的

根因(后来想清楚的):
1. ★ systemd 启动一个服务后,不是"启动完就不管了"。
   它会【持续盯着一个进程】,用这个进程死没死,
   来判断"服务还活不活着"。
2. ★ Type= 这个配置,就是告诉 systemd:你该盯哪个
   进程、那个进程退出意味着什么。它是一份【契约】。
3. 我没写 Type=,默认是 Type=simple。simple 的契约
   是:"我 ExecStart 的那个进程,【它自己】就是
   服务本体,它会一直在前台跑。"
4. ★ 可我的 start.sh,启动程序后【自己立刻就 exit】
   了(程序 --daemon 转入后台,脚本撒手不管)。
   systemd 盯着的是 start.sh 这个进程 —— 它一启动
   就退出了。
5. ★ systemd 一看"我盯的那个进程退出了" —— 按
   simple 的契约,这就等于"服务死了" —— 于是判
   failed,还会把这个服务 cgroup 里的其它进程
   (包括真正的 myapp)一起清理掉。
不是命令的错,是我没跟 systemd 说清楚"我是哪类服务"。

修复 1:start 成功,不等于服务真的起来了

# === ★ 先纠正一个误解:systemctl start 返回 0 是什么意思 ===

# === ★ start 返回 0 ≠ 服务在健康运行 ===
# systemctl start 的退出码,只说明"启动这个动作
#   被受理了、ExecStart 被执行了",它【不保证】
#   服务现在还活着、还健康。
# ★ 服务可能:启动后立刻崩了、启动后被 systemd 判
#   failed、启动了但进程是僵的 —— 这些情况下,
#   start 都可能给你一个 0。
# ★ 所以:start 之后,【必须】再确认一下状态。

# === ★ 确认服务真实状态的几个命令 ===
$ systemctl is-active myapp            # 最直接:active / failed / inactive
failed
$ systemctl status myapp               # 看详细:状态 + 最近日志 + Main PID
$ systemctl is-failed myapp            # 专门确认是不是 failed

# === ★ 看懂 status 输出里最关键的几行 ===
$ systemctl status myapp
   Active: failed (Result: exit-code)
#          ^^^^^^ ★ 这才是服务的真实死活
  Process: 9001 ExecStart=... (code=exited, status=0)
#                              ^^^^^^^^^^^^^^^^^^^^^^ ExecStart 进程的结局
   Main PID: 9001 (code=exited, status=0/SUCCESS)
#            ^^^^ ★ systemd 盯的"主进程"是谁、它现在怎样了
# ★ 重点理解:Main PID 那个进程的死活,直接决定
#   Active 状态。Main PID 退出了 -> 服务被判结束。

# === ★ Active 的几种状态,各是什么意思 ===
# active (running)  -> 服务在跑,有活着的进程。正常。
# active (exited)   -> ExecStart 跑完正常退出了,
#                      且 systemd 认为这是【预期的】
#                      (oneshot 类服务)。
# failed            -> ★ 出问题了:进程异常退出,
#                      或被判定为意外死亡。
# activating        -> 正在启动中(可能卡住了)。
# inactive (dead)   -> 没在跑(没启动 / 已停止)。

# === 认知 ===
# ★ "命令返回 0"和"服务健康运行"是两件事。start
#   之后一定 systemctl status / is-active 复核一下 ——
#   这次的弯路,从我把"返回 0"当成"成功"就开始了。

修复 2:systemd 是怎么判断"服务还活着"的

# === ★ 理解 systemd 和服务进程之间的关系 ===

# === ★ systemd 不是"启动完就走人" ===
# 很多人以为 systemd 像手动敲命令一样:执行 ExecStart,
#   程序跑起来,它的任务就完成了。★ 完全不是。
# systemd 是个【长期监管者】。它启动服务后,会
#   【一直盯着】这个服务,持续地判断:它还活着吗?
#   要不要重启它?

# === ★ 它盯的是"一个具体的进程" ===
# systemd 怎么知道服务死没死?它盯着一个被称为
#   【主进程(Main PID)】的具体进程。
# ★ 逻辑很简单:主进程还在 -> 服务活着;
#   主进程退出了 -> systemd 认为服务结束了
#   (是正常结束还是 failed,看退出码和 Type)。
$ systemctl status myapp | grep "Main PID"
   Main PID: 9001 (code=exited, ...)
# ★ 所以,"systemd 到底盯的是哪个进程",是
#   一切的关键。

# === ★ 一个服务往往不止一个进程:cgroup ===
# systemd 把一个服务启动的【所有】进程,都装进一个
#   叫 cgroup 的"盒子"里统一管理:
$ systemctl status myapp        # 输出底部有 CGroup 一段
   CGroup: /system.slice/myapp.service
           └─9001 /opt/myapp/start.sh
$ systemd-cgls /system.slice/myapp.service   # 看这个服务的进程树
# ★ 服务"停止"时,systemd 会把这个盒子里的进程
#   【全部】清理掉 —— 这点很重要(见修复 3 的坑)。

# === ★ 那个致命的问题:它盯错了进程怎么办 ===
# systemd 盯哪个进程当"主进程",【取决于 Type=】。
# 如果 Type= 配得不对,systemd 就会去盯一个【错误
#   的进程】 —— 盯着一个本来就该很快退出的进程,
#   然后在它退出时,误判"服务死了"。
# ★ 我这次的全部问题,就是这一句:systemd 盯错了
#   进程。它盯着我那个"启动完就 exit 的脚本",
#   脚本一退,它就判服务死了。

# === 认知 ===
# ★ systemd 判断服务死活,靠的是"盯住主进程"。
#   而"主进程是谁",由 Type= 决定。所以服务起不来、
#   秒退、被误杀,根子常常不在程序,在【Type= 让
#   systemd 盯错了进程】。

修复 3:Type= 是一份契约——四种类型的约定

# === ★ Type= 告诉 systemd:你该怎么理解我这个服务 ===

# === ★ Type=simple(默认)===
[Service]
Type=simple
ExecStart=/opt/myapp/bin/myapp        # ★ 这个程序必须【前台运行】
# 契约:"我 ExecStart 的那个进程,【它本身】就是
#   服务主体,它【不会】fork 到后台,会一直在前台
#   跑着。"
# ★ systemd 把 ExecStart 的进程直接当主进程盯。
# ★ 适用:现代程序,启动后就老老实实在前台待着的。
# ★ 我踩的坑:用了默认 simple,可我的脚本启动完
#   自己就 exit 了 —— 违背了"会一直前台跑"的契约。

# === ★ Type=forking(老式守护进程用这个)===
[Service]
Type=forking
ExecStart=/opt/myapp/bin/myapp --daemon
PIDFile=/var/run/myapp.pid            # ★ 配 forking 几乎必须配它
# 契约:"我 ExecStart 的进程会【fork 出子进程】,
#   然后【父进程自己退出】;真正的服务,是那个被
#   fork 出来、留在后台的【子进程】。"
# ★ systemd 看到父进程退出,【不会】判服务死 ——
#   它知道这是 forking 的正常行为,转而去认
#   PIDFile 里写的那个子进程当主进程。
# ★ 适用:会自我 daemon 化(转入后台)的老式程序。
# ★ PIDFile:程序把真正后台进程的 PID 写进这个文件,
#   systemd 靠它找到该盯哪个进程。不配,systemd
#   可能猜不准主进程。

# === ★ Type=notify(程序主动"报到")===
[Service]
Type=notify
ExecStart=/opt/myapp/bin/myapp
# 契约:"程序自己会通过 sd_notify 主动告诉 systemd
#   '我已经初始化好、可以服务了'。"
# ★ systemd 会【等】这个通知,收到了才认为启动完成。
#   最精确,但需要程序代码支持 sd_notify。

# === ★ Type=oneshot(跑完就完的一次性任务)===
[Service]
Type=oneshot
ExecStart=/opt/myapp/bin/init-data.sh
RemainAfterExit=yes
# 契约:"这不是常驻服务,是个跑一次就结束的任务。
#   进程退出是【预期】的,别判 failed。"
# ★ 适用:初始化脚本、一次性数据迁移等。

# === ★ 这次的对症:契约和现实必须一致 ===
# 我的程序行为是:fork 到后台、父进程退出 —— 这是
#   【forking 行为】。
# 而我声明的契约是 simple —— "我会一直前台跑"。
# ★ 行为是 forking,契约写的是 simple ->
#   systemd 按 simple 的契约理解一个 forking 的现实
#   -> 必然误判。改对 Type 就好(修复 5)。

# === 认知 ===
# ★ Type= 不是个可有可无的小配置。它是你和 systemd
#   之间的【契约】,声明了"我这个服务会怎样启动、
#   主进程是谁"。契约和程序的真实行为不符,systemd
#   就一定会判断错。

修复 4:看日志和状态——定位服务为什么起不来

# === ★ 服务起不来 / 秒退,这样一步步查 ===

# === 第一步:systemctl status 看个概况 ===
$ systemctl status myapp -l
# 重点看:
#  - Active: 那行 —— failed?activating 卡住?
#  - Process: / Main PID: —— ExecStart 进程的退出码
#  - 底部还会带最近几行日志

# === ★ 第二步:journalctl 看这个服务的完整日志 ===
$ journalctl -u myapp                  # 这个服务的所有日志
$ journalctl -u myapp -e               # 跳到最新
$ journalctl -u myapp --since "10 min ago"
$ journalctl -u myapp -f               # 实时跟踪(一边 start 一边看)
# ★ -u 指定 unit,是排查 systemd 服务的核心命令。
#   程序自己打到 stdout/stderr 的东西,systemd 都
#   收进 journal 了,这里能看到。

# === ★ 第三步:分清是哪一类失败 ===
# 看 status 里 ExecStart 进程的退出情况:
#  - status=0 (SUCCESS),却 failed
#    -> ★ 多半是 Type 错配(本文这次):进程正常
#       退出了,但 systemd 按契约不该看到它退出。
#  - status=非0 / signal=...
#    -> 程序自己启动就报错崩了。看 journalctl 里
#       程序打的错误(配置错、端口占用、缺文件...)。
#  - Active: activating 一直卡着,然后 timeout
#    -> ★ Type=notify 但程序没发通知;或 forking
#       但父进程迟迟不退。

# === ★ 第四步:start 失败时,先手动前台跑一遍 ===
# 把 ExecStart 那条命令,自己在命令行【前台】跑:
$ /opt/myapp/bin/myapp
# ★ 看它:
#  - 直接在前台一直跑、不退出 -> 它是个 simple 型程序。
#  - 立刻返回、进程转入后台 -> 它是 forking 型程序。
# ★ 这一步直接告诉你"程序真实行为是哪一类",从而
#   知道 Type 该配成什么。我这次手动一跑就看出:
#   start.sh 一下就结束了,可服务在后台 —— 典型 forking。

# === ★ 看服务的进程树,确认主进程 ===
$ systemctl status myapp        # 看 CGroup 段,有没有进程、是谁
$ systemd-cgls /system.slice/myapp.service

# === 认知 ===
# ★ 排查 systemd 服务,status 看概况、journalctl -u
#   看日志、手动前台跑一遍认清程序类型 —— 三件事
#   配合,基本能定位"起不来"的原因。

修复 5:正确解法——让契约和程序行为一致

# === ★ 解法:要么让程序配合 simple,要么如实声明 forking ===

# === ★ 解法 1(首选):让程序前台运行,用 Type=simple ===
# 现代 systemd 的最佳实践:★ 让程序【不要】自己
#   daemon 化,老老实实在前台跑,把"转入后台、
#   托管"这件事完全交给 systemd。
# - 很多程序有个"前台运行"的选项,去掉 --daemon:
[Service]
Type=simple
ExecStart=/opt/myapp/bin/myapp          # ★ 不带 --daemon,前台跑
# - ExecStart 不要用 "... &" 这种后台化写法,也不要
#   套一个"启动完就 exit 的脚本"。
# ★ 为什么首选这个:simple 最简单、最不容易错,
#   systemd 直接盯 ExecStart 进程,清清楚楚。

# === ★ 解法 2:老程序非要自我 daemon 化,如实写 forking ===
# 如果程序就是改不了、必须 --daemon,那就【如实】
#   把契约声明成 forking:
[Service]
Type=forking
ExecStart=/opt/myapp/bin/myapp --daemon
PIDFile=/var/run/myapp.pid              # ★ 关键:配上 PIDFile
# ★ 要点:
#  - Type=forking:告诉 systemd"父进程会退出,别
#    误判"。
#  - PIDFile:让 systemd 知道真正的后台进程是哪个。
#    程序必须能把后台进程 PID 写进这个文件。
# ★ 这样 systemd 就会去盯 PIDFile 里那个子进程,
#   而不是盯那个一闪而过的父进程。

# === ★ 解法 3:ExecStart 不要套"启动完就退"的脚本 ===
# 我最初的错:ExecStart 指向一个 start.sh,脚本里
#   把程序丢后台、自己 exit。★ 这对 simple 是灾难 ——
#   systemd 盯的是脚本,脚本一退服务就被判死。
# 要么 ExecStart 直接写程序前台命令;要么脚本结尾
#   用 exec 把自己【替换】成程序本体:
$ cat start.sh
#!/bin/bash
exec /opt/myapp/bin/myapp               # ★ exec:脚本进程"变成"程序进程
# ★ 用了 exec,脚本进程的 PID 不变、直接成了程序,
#   systemd 盯的就是真正的程序了。

# === ★ 解法 4:配好重启策略,提升健壮性 ===
[Service]
Restart=on-failure                      # 异常退出就自动重启
RestartSec=3                            # 重启前等 3 秒
# ★ on-failure:进程异常退出才重启(正常 stop 不重启)。
# ⚠ 但 Restart 治不了 Type 错配 —— Type 错的话,
#   它会"启动-误判死亡-重启"无限循环。先把 Type 配对。

# === ★ 解法 5:改完 unit 文件,记得 daemon-reload ===
# ★ 改了 .service 文件,systemd 不会自动知道,必须:
$ systemctl daemon-reload               # 让 systemd 重新读取 unit
$ systemctl restart myapp
# ★ 很多人改完 unit 没 reload,纳闷"怎么没生效" ——
#   就是漏了这步。

# === 验证 ===
$ systemctl daemon-reload
$ systemctl restart myapp
$ systemctl is-active myapp             # ★ 应为 active
active
$ systemctl status myapp                # Active: active (running)
$ journalctl -u myapp -e                # 日志里服务正常工作
$ systemctl enable myapp                # 别忘了配开机自启
# ★ is-active 是 active (running),且重启机器后还能
#   自己起来 —— 服务才算真正被 systemd 托管好了。

口诀放进脑子:Type= 是契约,程序前台跑就 simple,自我后台化就 forking。

修复 6:systemd 服务排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ systemctl start 返回 0 不等于服务健康,必须 status/is-active 复核 ===
$ systemctl is-active 服务名

# === 2. ★ systemd 是长期监管者,靠盯住"主进程"判断服务死活 ===

# === 3. ★ Type= 是契约,声明服务怎么启动、主进程是谁,配错 systemd 就盯错进程 ===

# === 4. 程序前台运行用 Type=simple;程序自我 daemon 化用 Type=forking + PIDFile ===

# === 5. ★ ExecStart 别套"启动完就 exit 的脚本",也别用 & 后台化,会被 simple 误判 ===

# === 6. status=0 却 failed,几乎就是 Type 错配:进程正常退出但契约不允许它退 ===

# === 7. ★ journalctl -u 服务名 看完整日志,程序的 stdout/stderr 都在里面 ===
$ journalctl -u 服务名 -e

# === 8. start 失败先手动前台跑一遍 ExecStart 命令,看程序真实行为是哪一类 ===

# === 9. ★ 改完 .service 文件必须 systemctl daemon-reload,否则改动不生效 ===

# === 10. 排查"服务起不来/秒退"的步骤链 ===
$ systemctl status 服务名             # ① 看 Active 和 Main PID 结局
$ journalctl -u 服务名 -e             # ② 看完整日志
$ 手动前台跑 ExecStart 命令            # ③ 认清程序是 simple 还是 forking
$ 把 Type= 配成和程序行为一致          # ④ 让契约和现实对齐
$ daemon-reload + restart + is-active # ⑤ 重载验证
# 按这个顺序,"服务起不来"基本能定位、能根治。

命令速查

需求                        命令
=============================================================
启动 / 停止 / 重启服务      systemctl start/stop/restart 服务名
查服务是否在运行            systemctl is-active 服务名
查服务详细状态              systemctl status 服务名 -l
查服务是否 failed           systemctl is-failed 服务名
看服务的完整日志            journalctl -u 服务名
看服务最新日志              journalctl -u 服务名 -e
实时跟踪服务日志            journalctl -u 服务名 -f
看服务的进程树              systemd-cgls /system.slice/服务名.service
改完 unit 文件后重载        systemctl daemon-reload
配置开机自启                systemctl enable 服务名
编辑 unit 文件              systemctl edit --full 服务名
看 unit 文件最终生效内容    systemctl cat 服务名

口诀:start 返回 0 不算成功,必须 systemctl status 看 Active 是不是 active running
      Type= 是契约,程序前台跑配 simple,自我转后台配 forking+PIDFile,配错就被误判

避坑清单

1. systemctl start 返回 0 只说明启动动作被受理,不代表服务在健康运行,必须 status 复核
2. systemd 不是启动完就走人,它是长期监管者,会一直盯着一个主进程来判断服务还活不活着
3. Type= 是你和 systemd 之间的契约,声明服务怎么启动、主进程是谁,配错 systemd 就会盯错进程
4. Type=simple 的契约是 ExecStart 进程一直前台运行,程序自我转入后台会违背它被判 failed
5. 程序会自己 fork 到后台用 Type=forking,并配 PIDFile 让 systemd 知道真正的后台进程是谁
6. ExecStart 别指向一个启动完就 exit 的脚本,也别用 & 后台化,simple 下会被立刻误判服务死亡
7. status 显示进程 status=0 正常退出却还 failed,几乎就是 Type 错配,进程退了但契约不允许
8. journalctl -u 服务名 看服务完整日志,程序自己打到标准输出和标准错误的内容都收在里面
9. start 失败先把 ExecStart 命令手动在前台跑一遍,看程序真实行为是一直前台还是 fork 后台
10. 改完 .service 文件必须 systemctl daemon-reload,否则 systemd 还用旧配置,改动不生效

总结

这次"服务启动命令返回 0、转头却 failed"的事故,纠正了我一个关于"启动"的、根深蒂固的画面。在我的脑子里,"启动一个服务",一直是一个【一次性的、有始有终的动作】。我把它想象成点火:我划一根火柴,凑过去,火点着了——这个"点火"的动作,到此就【完成】了,我可以转身离开。火着了之后它自己烧自己的,和我那个已经结束的"点火"动作,再没有关系。所以在我看来,systemctl start 就是那根火柴:它返回了 0,就意味着"火点着了",意味着我那个一次性的启动动作圆满收尾。我从没想过,systemd 在 start 返回之后,根本没有"转身离开"——它还站在原地,目不转睛地盯着。复盘到根上,我才明白,systemd 和我的服务之间,压根不是"点火"那种一次性的关系。systemd 不是个点火的人,它是个【监护人】。systemctl start 不是一个动作的结束,而是一段【长期监护关系的开始】。从那一刻起,systemd 就锁定了一个具体的进程,持续地、一刻不停地盯着它:它还在吗?它退出了吗?它退出得正常吗?systemd 就是用这个被盯住的进程的生死,来定义"服务"这个抽象东西的生死的。而这里有一个我从来不知道、却最为关键的环节:systemd 到底该盯【哪一个】进程,以及那个进程的退出到底意味着"正常完成"还是"意外死亡"——这些,它自己是不知道的,它需要我【提前告诉它】。这就是 Type= 的全部意义。Type= 不是一个无关紧要的小参数,它是我和这位监护人之间签下的一份【契约】,契约里写明了:我这个服务会以怎样的方式启动,启动之后,你该把哪一个进程认作我的"本体"。我那次的全部错误,就在于我从来没意识到这份契约的存在,于是我让它取了默认值——一份我根本没读过、却替我签了字的契约。这份默认契约(simple)向 systemd 承诺:"我交给你的那个进程,会一直待在前台,它就是服务本身。"可我的程序行为,却是另一回事:它启动后立刻把自己藏进了后台,把前台那个进程一脚踢开、让它 exit 了。systemd 这位尽职的监护人,死死盯着契约指给它看的那个前台进程——然后它眼睁睁看着这个进程退出了。它没有理由怀疑契约,它只能得出契约逻辑下唯一的结论:服务死了。它没有错。它只是忠实地履行了一份我亲手签下、却从未读过的契约。这次最大的收获,是我意识到,我习惯于关注"动作"本身——我做了什么、命令返回了什么——却严重忽视了"动作背后的那个关系"。一个 start 命令,我只看见了它"返回 0"这个瞬间,却完全没看见它开启的那段持续的、有约定的监护关系。而真正决定成败的,从来不是那个瞬间的动作,而是那段关系里,双方对"什么是正常、什么是死亡"的理解,到底有没有对齐。我和 systemd 之间,理解没有对齐——不是因为我们谁说错了话,而是因为我从来没有【认真说过话】,我让一份默认契约替我开了口,而它说的,不是我的真实情况。所以下一次,当我把一件事"托付"给一个系统去管理时——不管是托管一个进程、注册一个回调、还是把数据交给一个框架——我不会再只盯着"我交付出去"的那个动作了。我会停下来,把那份"托付契约"翻出来,一条一条地读:接管方,它【以为】我是什么样的?它【期待】我会怎样表现?它会用什么标准来判断我"还好"还是"出事了"?——很多失败,不是失败在你做的那个动作上,而是失败在你和接管方之间,那份你从未读过、却已默默生效的契约里。

—— 别看了 · 2026