LittleLink v3.11.0 主题定制与运维排障指南
LittleLink v3.11.0 主题定制与运维排障：主题三态/品牌视觉/自定义按钮/多实例定制实测流程，巡检三查、site 目录备份与误操作回滚实录、日志监控与 HTTP 拨测、升级增量同步与双层回滚，含 403/端口冲突/图标404/品牌类拼写/静态资源缓存五案例排障决策树。
LittleLink v3.11.0 主题定制与运维排障指南
目标：解决 LittleLink 上线后的两类问题——怎么把它改成自己的样子（主题三态、品牌视觉、自定义按钮、多实例独立外观），以及怎么把它养好（日常巡检、备份恢复、日志监控、升级回滚、六类故障的排障手册）。LittleLink 没有 CLI、没有管理后台，全部操作都是「文件编辑 + compose 命令 + 日志分析」；本文所有命令与回显均已在 Ubuntu 24.04.5 LTS 服务器、Docker Compose 部署的 LittleLink v3.11.0 主实例（8141）与第二实例（8144）上实测。部署过程见 《LittleLink Docker Compose 部署指南》，逐字段参数含义见 《LittleLink v3.11.0 配置参数详解》。
一、环境信息
| 项目 | 值 |
|---|---|
| 操作系统 | Ubuntu 24.04.5 LTS（7.0.0-38-generic，x86_64） |
| Docker / Compose | 29.9.2（build a82e528）/ v5.6.1 |
| 组件版本 | LittleLink v3.11.0（2026-07-28 发布，MIT） |
| 镜像 | littlelink:v3.11.0（自建，95.1MB，基础镜像 nginx:alpine / nginx/1.31.8） |
| 主实例 | compose 项目 littlelink，容器 littlelink-web-1，端口 8141，站点 /opt/littlelink/site |
| 第二实例 | compose 项目 littlelink-jane，容器 littlelink-jane-web-1，端口 8144，站点 /opt/littlelink-jane/site |
| 网络 | 10.89.68.0/24（主）、10.89.69.0/24（第二实例） |
| 配置载体 | site/index.html（文件即配置，改完即生效、无需重启） |
本文的定制与运维操作全部在 compose 项目目录（如 /opt/littlelink/）内执行。LittleLink 无登录体系、无管理后台，因此不存在账号/权限类运维事项；日志中出现的客户端 IP 属于访客数据，本站不落地任何分析（组件本身无 analytics）。
二、主题定制实战
「定制」在 LittleLink 里 = 编辑挂载目录里的 index.html（及替换 images/ 下的图片）。本章按上线常见顺序走一遍完整定制流：主题 → 品牌视觉 → 按钮 → 多实例，每步都给出线上验证回显。参数级含义见配置详解篇，这里只讲操作。
2.1 主题三态切换
首行 <html class="theme-auto"> 的 class 三选一（theme-auto / theme-light / theme-dark），改站点文件即可，无需重启：
cd /opt/littlelink/site
sed -i 's|<html class="theme-auto"|<html class="theme-dark"|' index.html
curl -s http://localhost:8141/ | grep -n 'class="theme'
10:<html class="theme-dark" lang="en"> <!-- Update `class="theme-auto"` with your preference -->
解读：theme-dark 强制深色（body 背景 #121212、正文白字）；theme-auto 跟随访客系统深浅色；theme-light 强制亮色。三态的实现细节（color-scheme 与 prefers-color-scheme 媒体查询）见配置详解篇 5.1。
💡 技术拓展：「主题」这个词在 LittleLink 页面里对应三个不同层面的东西，定制时容易混淆，全量区分——
层面 载体 控制什么 改错的表现 页面配色主题 <html class="theme-*">（index.html 10 行）页面本身深/浅色 页面配色与预期不符 浏览器 UI 色 <meta name="theme-color">×2（30-31 行，按 light/dark 媒体查询分条）手机浏览器地址栏/状态栏配色 页面深色但地址栏仍白 访客系统偏好 访客 OS 的深色模式设置（ prefers-color-scheme）仅 theme-auto时影响页面不是你的配置，是访客的 三者相互独立：强制
theme-dark后访客系统浅色也不变页面配色，但 31 行theme-color的 dark 条目#121212仍会生效于手机地址栏——改主题时把 10 行与 30-31 行当作一组一起核对。
2.2 品牌视觉：标题、简介、头像与 favicon
四个位置一次改齐（全部在 index.html + images/）：
sed -i 's|<title>LittleLink</title>|<title>Quzuo Labs - 链接导航</title>|' index.html
sed -i 's|<h1>LittleLink</h1>|<h1>Quzuo Labs</h1>|' index.html
curl -s http://localhost:8141/ | grep -n '<title>'
17: <title>Quzuo Labs - 链接导航</title>
头像替换是把 site/images/avatar.png 与 avatar@2x.png 换成自己的 128×128 / 256×256 图片（文件名不变则 HTML 零改动）。实测用 128×128 纯色 PNG 覆盖官方占位头像（10986 字节）后，响应头立即反映新文件：
curl -sI http://localhost:8141/images/avatar.png | grep -E 'HTTP|Content-Length'
HTTP/1.1 200 OK
Content-Length: 307
解读：favicon（18 行 <link rel="icon">）默认就指向 images/avatar.png，换头像即换 favicon；<p> 简介行（82 行）直接改标签内文本。srcset 的 2x 图是独立文件，两张都要换，否则高分屏显示旧图。
2.3 自定义品牌按钮
官方 91 个品牌类之外的链接，用「<style> 注入 + 三个 CSS 变量」接入，不动任何 css 文件。在 index.html 的 <head> 加：
<style>.button-quzuo { --button-text:#ffffff; --button-background:#083BDA; --button-border:1px solid #083BDA; }</style>
在 <nav class="button-stack"> 内加一行：
<a class="button button-quzuo" href="https://www.quzuo.net" target="_blank" rel="noopener"><img class="icon" aria-hidden="true" src="images/icons/littlelink.svg" alt="Quzuo Logo">我的自托管文档站</a>
线上验证（实测回显）：
curl -s http://localhost:8141/ | grep -nE 'button-quzuo'
90: .button-quzuo {
96:<a class="button button-quzuo" href="https://www.quzuo.net" target="_blank" rel="noopener"><img class="icon" aria-hidden="true" src="images/icons/littlelink.svg" alt="Quzuo Logo">我的自托管文档站</a>
解读：自定义类与官方 .button-github 完全同构（都是给 --button-text/--button-background/--button-border 三变量赋值），悬停效果由基类自动继承。此时页面体积从默认 31818 字节变为 32405 字节——Content-Length 是「定制是否落盘」的最快判据。生产页面还应删掉其余 120 个空壳示例按钮（href="#"），方法与排序调整见配置详解篇 5.4/6。
2.4 多实例独立外观
每个实例挂自己的 site/，定制互不影响。第二实例（/opt/littlelink-jane/，端口 8144）改成了浅色主题与个人标题，实测：
curl -s http://localhost:8144/ | grep -nE 'class="theme|<title>' | head -2
curl -sI http://localhost:8144/ | head -1
10:<html class="theme-light" lang="en"> <!-- Update `class="theme-auto"` with your preference -->
17: <title>Jane Doe - 个人链接页</title>
HTTP/1.1 200 OK
解读：主实例 theme-dark、Jane 实例 theme-light，同一镜像 littlelink:v3.11.0 各挂各的站点目录——「镜像管运行时、挂载管内容与外观」是多实例定制成立的前提（部署机制见部署指南篇「八、配置文件挂载」「十、多实例部署」）。
三、日常巡检
静态站点的巡检面很窄：服务活着吗、资源正常吗、站点文件完整吗。三条命令各答一问。
3.1 存活与内容判据
curl -s -o /dev/null -w '%{http_code} %{time_total}s %{size_download}B\n' http://localhost:8141/
docker compose ps
200 0.000577s 32405B
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
littlelink-web-1 littlelink:v3.11.0 "/docker-entrypoint.…" web 12 seconds ago Up 11 seconds 0.0.0.0:8141->80/tcp, [::8141->80/tcp]
解读：200 + 32405B 同时验证了两件事——nginx 在服务、且吐出的是定制后的页面（默认页是 31818B）。若状态码 200 但字节数回落到 31818，说明挂载被换掉了（比如 compose 的 volumes 行被误删后重建了容器）。
3.2 资源占用
docker stats --no-stream littlelink-web-1
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
3d19941b4a82 littlelink-web-1 0.00% 6.645MiB / 15.57GiB 0.04% 13.3kB / 367kB 0B / 4.1kB 7
解读：nginx 常驻仅 6.6MiB、7 进程，静态站点的容量瓶颈在带宽而非算力；巡检时只需关注两件事——内存是否异常增长（正常应稳定在个位数 MiB）与 docker compose ps 的 STATUS 是否出现 Restarting（见排障手册 7.2/7.3）。
3.3 站点完整性核对
把「容器里看到的」与「源码目录的默认状态」对一遍，确认定制范围没有失控：
docker compose exec web sh -c 'find /usr/share/nginx/html -type f | wc -l'
for f in index.html css/brands.css css/style.css privacy.html; do
diff -q "littlelink-3.11.0/$f" "site/$f" >/dev/null 2>&1 && echo "SAME $f" || echo "DIFF $f"
done
ls site/images/icons | wc -l
grep -c '^\.button-' littlelink-3.11.0/css/brands.css
139
DIFF index.html
SAME css/brands.css
SAME css/style.css
SAME privacy.html
123
91
解读：容器内 139 个文件与宿主站点目录一致；四个关键文件中只有 index.html 与官方默认不同（DIFF）——这正是预期定制面（样式表与隐私页未动）。图标 123 个、品牌类 91 个与官方 v3.11.0 一致。若某天 brands.css 意外变成 DIFF，要么有人改了样式（确认意图），要么被升级覆盖流程弄脏（见「六、升级与回滚」）。
四、备份与恢复
LittleLink 的全部可恢复状态就是 site/ 目录（镜像可随时重建，日志由 Docker 驱动管理），备份 = 打包目录。
4.1 备份与校验
cd /opt/littlelink
tar -czf site-$(date +%F).tar.gz -C . site
ls -lh site-*.tar.gz
sha256sum site-*.tar.gz
-rw-r--r-- 1 root root 415K Nov 3 02:30 site-2026-11-03.tar.gz
1cb7f3c76f8c5bfd2b3ffc6068c538e2e3eba2544c369b29679f0500b8c373ed site-2026-11-03.tar.gz
解读：415K 即全站（含 123 个图标与 4 个 woff2 字体）。建议每次批量改配置前先打一个包，并把 sha256sum 记进变更说明——恢复后比对哈希即可确认「恢复到位且没有多余改动」。更严格的版本管理是把 site/ 直接纳入 git（文件即配置，diff/review/回滚免费，见配置详解篇 6 节要点 5）。
4.2 恢复与回滚实录
以下是一次完整的「误操作 → 回滚」实测。备份后记录当前 index.html 的哈希，然后模拟一次误编辑：
md5sum site/index.html
sed -i 's|<title>Quzuo Labs - 链接导航</title>|<title>误操作标题</title>|' site/index.html
curl -s http://localhost:8141/ | grep -n '<title>'
c23638d3f623d102a67c7f6bd5def54c site/index.html
17: <title>误操作标题</title>
误编辑经挂载即时生效到了线上（这正是「文件即配置」的双刃剑）。用 4.1 的备份包恢复：
tar -xzf site-2026-11-03.tar.gz
md5sum site/index.html
curl -s http://localhost:8141/ | grep -n '<title>'
curl -sI http://localhost:8141/ | grep -E 'HTTP|Content-Length'
c23638d3f623d102a67c7f6bd5def54c site/index.html
17: <title>Quzuo Labs - 链接导航</title>
HTTP/1.1 200 OK
Content-Length: 32405
解读：恢复后 md5 与备份前完全一致、线上标题复原、页面回到定制态的 32405 字节。tar -xzf 解在项目目录会整目录覆盖 site/——所以恢复前先 md5sum 留证，避免把「想保留的新改动」一起冲掉；只想恢复单个文件时，用 tar -xzf 包 site/index.html 精确解出该文件即可。全程无需重启容器。
4.3 异地备份（建议方案）
本机 tar 包防不住磁盘故障，推荐 cron 每日备份并同步到异地（以下命令为推荐配置，非本文实测项）：
# crontab -e 追加：每天 03:30 备份 site 并保留最近 14 份，rsync 到备份机
30 3 * * * cd /opt/littlelink && tar -czf site-$(date +\%F).tar.gz -C . site && find . -name 'site-*.tar.gz' -mtime +14 -delete && rsync -a site-*.tar.gz backuphost:/backup/littlelink/
五、监控与日志分析
LittleLink 没有 metrics 端点、没有应用日志——可观测面只有 nginx 的 access/error 流（官方 Dockerfile 已软链到 stdout/stderr，docker compose logs 直接可看）。
💡 技术拓展：自托管组件的监控形态通常三选一，静态站点的选择面最窄——
形态 原理 LittleLink 适用性 Metrics 抓取（Prometheus 等） 应用暴露 /metrics供拉取✗ 无此端点，需外挂 nginx exporter 才有指标 日志分析（本文） access/error 流统计状态码与错误 ✓ 日志已进 stdout， docker compose logs即数据源HTTP 拨测（合成监控） 周期请求首页比对状态码/内容 ✓ 一条 curl 即可，最适合静态站
5.1 访问日志状态码统计
docker compose logs --since 24h 2>&1 | grep -oE 'HTTP/1.1" [0-9]{3}' | awk '{print $NF}' | sort | uniq -c | sort -rn
14 200
1 404
解读：24 小时内 14 个 200、1 个 404。静态站点的日志巡检只看两个信号：404 计数（图标/样式缺失，逐条定位见 7.4）与 403/500 类计数（挂载或配置坏了，见 7.3）。404 的那一条正是本章 5.2 的 error 日志。
5.2 错误日志定位
docker compose logs --since 24h 2>&1 | grep '\[error\]' | tail -2
web-1 | 2026-11-02 18:19:15 [error] 32#32: *5 open() "/usr/share/nginx/html/css/brands-extended.css" failed (2: No such file or directory), client: 10.89.68.1, server: localhost, request: "GET /css/brands-extended.css HTTP/1.1", host: "localhost:8141"
解读：error 行直接给出缺失文件在站点根下的精确路径（本例是启用了 brands-extended.css 引用但没放文件，属配置详解篇 5.7 的实验残留）。巡检发现 404 时，用这条命令拿到路径 → 对照 site/ 下实际文件 → 修 HTML 引用或补文件，闭环不需要额外工具。
5.3 HTTP 拨测
单条命令可做 cron 拨测（实测回显）：
curl -s -o /dev/null -w '%{http_code} %{time_total}s %{size_download}B\n' http://localhost:8141/
200 0.000577s 32405B
推荐 cron 形态（判据：状态码非 200 或字节数偏离预期即告警）：
*/5 * * * * curl -sf -o /dev/null http://localhost:8141/ || /usr/local/bin/notify "littlelink down"
已有 Uptime Kuma / Prometheus blackbox 类拨测体系的，把首页 URL 加进去即可，判据同上；公网域名场景建议对 https://<域名>/ 拨测（HTTPS 由反代终结，见 FAQ Q3）。传输层健康可顺带核对 gzip：curl -sI -H 'Accept-Encoding: gzip' http://localhost:8141/ | grep -i content-encoding 返回 Content-Encoding: gzip 即镜像内 gzip 配置在位。
六、升级与回滚
LittleLink 的升级 = 「重建镜像 + 按需同步站点新增文件」，因为页面内容在挂载目录里，升级不会覆盖你的定制——这是挂载模式最省心的一点，也是最容易误解的一点。
6.1 版本核对与新版发现
当前版本以源码目录官方记录为准（不靠猜）：
head -4 /opt/littlelink/littlelink-3.11.0/VERSION.md
# LittleLink Version History
## Current Version: v3.11.0
新版本用官方发布订阅源实查（实测回显，最新条目时间 2026-07-29 即 v3.11.0 的发布记录）：
curl -s https://github.com/sethcottle/littlelink/releases.atom | grep -m3 -E '<title>|<updated>'
<title>Release notes from littlelink</title>
<updated>2026-07-29T04:31:15Z</updated>
<updated>2026-07-29T04:49:45Z</updated>
解读：releases.atom 首条 <updated> 晚于你记录的版本时间，即有新版。拿到新版本号 vX.Y.Z 后进入 6.2。
6.2 升级流程
按部署指南篇 3.3 同款渠道下载新源码（当前实测唯一可用渠道为 curl 直连官方 tarball）：
cd /opt/littlelink
curl -LO https://github.com/sethcottle/littlelink/archive/refs/tags/vX.Y.Z.tar.gz
tar -xzf vX.Y.Z.tar.gz
把 compose 的 build.context 与 image 标签指到新版目录后重建：
docker compose up -d --build
回显与首次构建完全一致（Image littlelink:v3.11.0 Built → Container littlelink-web-1 Started，见部署指南篇 4.2 的实测回显，其中镜像名/版本号随 image: 键同步变为新版值）。
关键一步是站点新增文件的增量同步：site/ 不会被升级覆盖，新版新增的图标、品牌类若不同步，就会出现「新按钮无样式 / 新图标 404」。用 diff 找出新版源码与挂载目录的差异再同步。当前环境（site 与同版本源码对照）实测基线：
diff -rq littlelink-3.11.0/css site/css
diff -rq littlelink-3.11.0/images/icons site/images/icons
（两条命令均无输出，退出码 0——样式表与 123 个图标完全一致）
升级后对新版目录重复执行同样命令，输出即「需要人工同步的清单」：Files ... differ 的行先 diff 看内容再决定合并方式（若你从未改过样式表，直接拷新版覆盖即可）；Only in <新版源码>/... 的新图标按需拷贝进 site/images/icons/。同步后无需重启，刷新即生效。
6.3 回滚
两个层面各自独立回滚：
- 站点内容：直接用 4.1 的备份包恢复（
tar -xzf site-<日期>.tar.gz），实测闭环见 4.2； - 镜像/运行时：把 compose 的
build.context指回旧版源码目录、image标签改回旧版本号，docker compose up -d --build即回滚——旧源码目录（如littlelink-3.11.0/）在升级时不要删除，就是为这一刻留的。
静态站点没有数据迁移问题（无数据库），回滚的全部成本就是这两步。
七、排障手册
先给决策树，再按现象逐案展开。五个案例的现象与定位回显均为实测复现。
页面异常
├─ 浏览器连不上（拒绝连接/超时）
│ ├─ docker compose ps 无容器/STATUS=Restarting → 查 docker compose logs 尾部报错
│ └─ 容器 Up 但端口不通 → 7.2 端口冲突
├─ HTTP 403 Forbidden → 7.3 空挂载
├─ HTTP 200 但视觉异常
│ ├─ 图标位置空白/裂图 → 7.4 图标 404
│ ├─ 某个按钮没配色 → 7.5 品牌类拼写
│ └─ 改了 CSS 页面不变 → 7.6 静态资源缓存
└─ 改了 index.html 页面没变 → 先 curl -sI 看 Content-Length：
数值已变=浏览器缓存（7.6 同法强刷）；数值未变=编辑的不是挂载文件（核对 volumes 路径）
7.2 端口冲突：容器起不来
现象（对已占用的 8141 再起实例）：
docker run -d --name littlelink-dup -p 8141:80 littlelink:v3.11.0
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint littlelink-dup (9a5f1c9ee8e93c5ff7cea666a51213a9380ff4f87b8dfaefb0df14894dc7380a): Bind for 0.0.0.0:8141 failed: port is already allocated
Run 'docker run --help' for more information
定位占用者：
ss -ltnp | grep ':8141'
LISTEN 0 4096 0.0.0.0:8141 0.0.0.0:* users:(("docker-proxy",pid=574681,fd=8))
LISTEN 0 4096 [::]:8141 [::]:* users:(("docker-proxy",pid=574688,fd=8))
解读：docker-proxy 说明占用者本身就是某个容器——docker ps --format '{{.Names}} {{.Ports}}' 对照找到它（本例为主实例 littlelink-web-1）。遗留实验容器 docker rm -f 清掉即可；确属规划冲突则改新实例的宿主侧端口（容器内 listen 80 写死在镜像配置里，改端口只动 compose 的 ports，见部署指南篇「六、」注意事项）。
7.3 HTTP 403：站点目录挂空了
现象（实测复现：把空目录挂进站点根）：
mkdir -p /opt/littlelink/empty-site
docker run -d --name littlelink-empty -v /opt/littlelink/empty-site:/usr/share/nginx/html littlelink:v3.11.0
docker exec littlelink-empty sh -c 'ls -A /usr/share/nginx/html | wc -l'
IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' littlelink-empty)
curl -sI http://$IP:80/ | head -2
0
HTTP/1.1 403 Forbidden
Server: nginx/1.31.8
定位链：403（而非 404）→ nginx 找不到 index.html 且 autoindex 关闭 → 挂载点文件数为 0。根因几乎都是 compose 的 volumes 路径写错，Docker 静默创建了不存在的宿主目录。修复：核对 volumes 指向真实站点目录、把文件放进去（或按 4.2 从备份恢复），清理错误实例：
docker rm -f littlelink-empty
curl -sI http://localhost:8141/ | head -1
littlelink-empty
HTTP/1.1 200 OK
7.4 图标 404：按钮图片不显示
现象（引用不存在的图标）：
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8141/images/icons/nonexistent.svg
docker compose logs --tail 2
404
web-1 | 2026-11-02 17:52:10 [error] 29#29: *10 open() "/usr/share/nginx/html/images/icons/nonexistent.svg" failed (2: No such file or directory), client: 10.89.68.1, server: localhost, request: "GET /images/icons/nonexistent.svg HTTP/1.1", host: "localhost:8141"
web-1 | 10.89.68.1 - - [02/Nov/2026:17:52:10 +0000] "GET /images/icons/nonexistent.svg HTTP/1.1" 404 153 "-" "curl/8.5.0"
解读：error 行给出站点根下的精确缺失路径。两类根因：手写按钮 src 拼错，或升级后引用了尚未同步的图标（见 6.2）。修复：ls site/images/icons/ 对照 123 个官方 SVG 文件名改 src，或从新版源码补文件；改完刷新即生效。批量核对可用：grep -oE 'images/icons/[a-z0-9-]+\.svg' site/index.html | sort -u 列出页面引用的全部图标，再与目录清单 diff。
7.5 按钮没了颜色：品牌类拼写错误
现象（无报错，按钮变透明底黑字）。实测复现：复制 GitHub 按钮、class 写成 button-gitub（少个 h）：
grep -c 'button-gitub' css/brands.css
curl -s http://localhost:8141/ | grep -c 'button-gitub'
0
1
解读：样式表里不存在该类（0）、HTML 里却引用了（1）——基类的三个 CSS 变量都带回退值（背景 transparent、文字 #000000），所以不报错、不 404，只是「没颜色」。修复：grep -o '^\.button-[a-z0-9-]*' css/brands.css 列出 91 个合法类名对照拼写；自有品牌按 2.3 自建变量类兜底。
7.6 改了 CSS/图标不生效：静态资源缓存
镜像内 nginx 对 css/js/图片/SVG 统一 expires 7d（实测响应头）：
curl -sI http://localhost:8141/css/brands.css | grep -iE 'HTTP|expires|cache-control'
HTTP/1.1 200 OK
Expires: Mon, 09 Nov 2026 18:02:36 GMT
Cache-Control: max-age=604800
Cache-Control: public
而 index.html 无缓存头——所以「HTML 改动立即可见、样式改动滞后」是缓存而非配置未生效。先证明服务端已经更新：
curl -sI http://localhost:8141/css/brands.css | grep Content-Length
wc -c site/css/brands.css
Content-Length: 11597
11597 site/css/brands.css
解读：响应头与磁盘文件字节数一致（11597）→ 服务端已是新内容，浏览器侧强制刷新（Ctrl+Shift+R）即可。长期方案：反代层给静态资源加版本查询串，或自建 Dockerfile 覆盖 default.conf 缩短缓存期（见部署指南篇「六、」「七、」）。
八、常见问题
Q1：能不能直接 docker compose exec 进容器改文件？
可以，而且改的就是宿主文件——bind mount 下容器视图与宿主视图是同一份数据（实测两侧 md5 一致）：
docker compose exec web md5sum /usr/share/nginx/html/index.html
md5sum site/index.html
c23638d3f623d102a67c7f6bd5def54c /usr/share/nginx/html/index.html
c23638d3f623d102a67c7f6bd5def54c site/index.html
但不建议：容器内没有趁手的编辑器（alpine + vi），且一旦哪天改用「文件打进镜像」的方式部署，容器内手工改动就与宿主副本脱钩了。统一在项目目录编辑 site/ 是纪律。
Q2：升级后新版新增的图标/品牌样式会自动出现在我的页面吗？
不会。升级只重建镜像，site/ 挂载目录原样保留（这正是定制不被覆盖的代价对称面）。新版差异用 6.2 的 diff -rq 找出、按需同步；只同步文件还不够，按钮要自己加进 index.html 才会出现。
Q3：LittleLink 自己不支持 HTTPS，公网怎么上 TLS？
组件层面无任何 TLS/证书配置入口（nginx 配置 listen 80 写死在镜像里）。标准做法是前置反代终结 TLS：Caddy（自动证书）或既有 nginx 反代 proxy_pass 到 8141，反代层顺手可加访问日志聚合与缓存策略调整。上 HTTPS 后记得同步改 index.html 里的 canonical、OG 的 og:url/og:image 为 https 绝对地址（见配置详解篇 5.2）。
Q4：改 HTML 改坏了（页面空白/结构错乱），最快恢复路径是什么？
按破坏范围二选一：只坏了 index.html → 从源码目录拷默认文件回挂载再重放定制（cp littlelink-3.11.0/index.html site/），或从 4.1 备份包精确解出 site/index.html；整目录被污染 → 4.2 的整包恢复实录照做。任何情况都不需要重启容器。
九、参考链接
- LittleLink 官网：https://littlelink.io
- 官方仓库（源码/VERSION.md/Dockerfile）：https://github.com/sethcottle/littlelink
- 发布订阅源（升级判据）：https://github.com/sethcottle/littlelink/releases.atom
- 扩展品牌库 LittleLink Extended：https://github.com/sethcottle/littlelink-extended
- nginx 缓存指令（expires/Cache-Control）：https://nginx.org/en/docs/http/ngx_http_headers_module.html
- 部署与镜像构建：《LittleLink Docker Compose 部署指南》
- 配置逐字段详解：《LittleLink v3.11.0 配置参数详解》
- 同类面板运维参考：《homepage v2.7.0 运维与排障指南》