家用 iMac 服务器改造方案

版本：V02.16 | 更新：2026-07-27 11:21 | 状态：需求基本定稿，进入试水部署（新增跑偏分支预留清单 + 模拟执行手册 + 打磨机制补充第 6 条 + 跑偏清单确认保留 + 电源与容量扩展预案 + 全文逻辑审查修正） 面向：需求方 | 场景：Apple Silicon iMac + MBA 随时随地操作 + 对外展示 目标：把闲置 iMac 改造成个人服务器——核心是「MBA 随时随地稳定操作 iMac」+「对外仅展示内容」

📋 版本控制

变更记录

需求打磨大原则（v0.4 确立 · 2026-07-23 07:52 · 2026-07-27 补充第 6 条）

1. 每次需求方提出需求细化想法或疑问后，针对性回答的内容在本文档内做新增/修改的明确标注。
2. 标注格式采用「我问 → 你答 → 解释」的方式，并记录具体发生的时间。
3. 文档做版本控制：每次迭代更新变更记录表。版本号规范（V01.00 起采用）：V 大写；主版本号=大改（重大功能/结构/内容调整）+1，两位补零（V01→V02…）；二级版本号=小改（修补/细化）.01~.99；大改后二级归零；初版 V01.00。判定不确定时反馈需求方定夺。
4. 每次反馈都必须将最新一版文档给到需求方，确保有反馈、可阅读。
5. 发现需求前后有矛盾或设计思路冲突时，及时提醒并给出供选择的建议。
6. 悬而未决问题交付前确认（2026-07-27 补充）：遇到悬而未决的问题，或我认为有必要让需求方做出判断确定的问题，都在每次交付前通过提问（给选项让需求方选定择/确认）的方式，在思考过程中等待需求方确认后再继续，不擅自绕过。① 不重复提醒"还有悬而未决的问题"——每个问题按需提一次即可；② 同一问题问过三遍、需求方仍无明确回应，则自行判断（非真遗留问题 / 已自行解决），不再追问、按合理默认推进或归档；③ 适用范围：所有项目统一生效，与"不擅作主张 + 主动追问"一脉相承。

当前决策状态总览

🟢 已明确 🟡 待你确认 🔴 需补课（安全防护/日常运维，方案见十二章）

一、先说结论

技术上完全可行，而且你的条件相当不错：

• Apple Silicon：省电（全天开一个月电费几块钱）、性能强、几乎无声，比老 Intel 机器适合 7×24 运行。
• 网络类型待确认【v0.2 修改】：你有没有公网 IP，决定展示通道走端口转发（免费、最快）还是内网穿透（免费、偏慢）。但操作通道不受影响——无论有没有公网 IP，远程操作 iMac 的方案一样。【v0.5 补充】
• 定位已明确【v0.5 确认】：自用 + 预留对外扩展。核心诉求是「MBA 随时随地稳定操作 iMac」+「对外仅展示内容」。
• 域名已就位【v0.8 确认】：你已有 sixstars.cn（未备案），stocktrading 子域名已跑通。"买域名"这步省了，但未备案特性影响展示通道——见矛盾观察 3。

和腾讯云的本质差距在三个地方，方案里都会逐一解决或规避：

1. 没有公网 IP / IP 会变 → 两条路都准备好，判断完走对应的
2. 家庭宽带封 80 端口、上行带宽小 → 用非标准端口 + 反向代理统一管理
3. 电力/网络不如机房稳 → UPS 扛短停 + 远程开机预案 + 监控告警（注：Apple Silicon iMac 断电不自动开机，见十二章）

二、整体架构

【v0.5 重构】方案的核心是两条独立通道，分别解决两个需求：

┌─────────────────────────────────────────────────────────┐
│  通道 1：操作通道（第一优先级 · 刚需）                      │
│  MBA ──随时随地──→ 操作 iMac                              │
│                                                          │
│  在家同WiFi：内网直连（零成本零延迟）                       │
│  在外：Cloudflare Tunnel + Access 认证（详见第1层/第6层）   │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  通道 2：展示通道（第二优先级 · 展示炫耀）【V02.01 定位】   │
│                                                          │
│  静态展示 → EdgeOne Pages（分支C，已验证，iMac 不用开）     │
│  动态服务 → iMac 本地（分支A/B，iMac 必须常开）             │
│    有公网IP：DDNS + 端口转发 + NPM（国内直连最快）         │
│    无公网IP：Cloudflare Tunnel + NPM（免费但偏慢）         │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│  iMac (Apple Silicon)                       │
│                                             │
│  [反向代理 NPM]  展示通道的统一入口+HTTPS     │
│       │                                     │
│  [OrbStack + Portainer] 容器引擎+图形管理    │
│       │                                     │
│  [服务层] 展示用Web应用 / 数据库 / 文件存储   │
│       │                                     │
│  [Uptime Kuma] 服务在线监控 + 告警           │
│                                             │
│  管理界面（9xxx端口）：不挂公网域名            │
│    在家→内网IP访问；在外→Tunnel+Access认证   │
└─────────────────────────────────────────────┘

关键设计原则【v0.5 新增 · v0.6 补充】：

• 操作通道是管理面，需要认证保护，不裸暴露公网。
• 展示通道是数据面，可以公网开放，但只暴露反向代理端口。
• 两条通道技术方案可以不同，互不影响。
• 「方便优先·保留预案」原则【v0.6 新增】：设计时以「怎么更方便需求方处理各种情况」为优先导向——主流方案先做够用，但每层都预留扩展接口和 fallback 预案，平时不启用，需要时能快速接入，不用推倒重来。

三、分层方案详解

第 1 层：网络层 —— 双通道 + 双分支设计【v0.5 重构】

之前网络层只讲"怎么让外面访问进来"。v0.5 重构后，明确拆成两条通道，且有无公网 IP 两条路都写清楚——你不用等判断完，两条路的方案都已就位。

核心概念：你的需求其实是两条独立的通道

先判断：你有没有公网 IP？

公网 IP 就是"互联网上别的电脑能直接找到你的地址"。家庭宽带分两种情况：

• 有公网 IP：你的路由器有一个互联网上的独立地址，外面能直接连进来（地址可能会变，叫"动态公网 IP"，用 DDNS 自动更新即可）。
• 大内网 / 无公网 IP：运营商用一个大 NAT 把很多用户共用一个地址，外面根本连不到你家路由器。现在家宽这种情况越来越常见。

1. 浏览器打开 ip138.com（或 cip.cc），记下显示的 IP——这是"外网看到的你"。
2. 登录路由器后台（一般是 192.168.1.1 或 192.168.0.1），找"WAN 口状态"或"上网状态"，记下 WAN IP——这是"路由器拿到的地址"。
3. 对比两个 IP：

判断方法（3 步）：

• 两个一致 → 有公网 IP（走分支 A）
• 不一致，或 WAN IP 是 100.64.x.x~100.127.x.x、10.x、172.16~31.x → 大内网，无公网 IP（走分支 B）

重要【v0.5】：无论判断结果是什么，操作通道的方案完全一样。公网 IP 只影响展示通道走哪条路。所以你不用纠结"没公网 IP 怎么办"——没公网 IP 照样能随时随地操作 iMac，只是对外展示会慢一点。

分支 A：有公网 IP

通道 1（操作）：Cloudflare Tunnel + Cloudflare Access

• 在 iMac 上跑 cloudflared，它主动连到 Cloudflare（出站连接，不需要端口转发）。
• 通过 Cloudflare Access 给管理界面加一层零信任认证（邮箱验证码登录），不裸暴露公网。
• 为什么操作通道不用端口转发？ 管理界面（Portainer、NPM 后台）直接暴露公网太危险，全球扫描机器人 7×24 在扫。Cloudflare Access 比强密码更安全，且免费。
• 代价：国内访问走 Cloudflare 境外节点，延迟 300~800ms。Web 管理界面够用；如果是远程桌面操作可能略卡（见矛盾观察 2）。
• 在家时不用走这条路：同一 WiFi 下直接用内网 IP 访问，零延迟。

通道 2（展示）：DDNS-GO + 端口转发 + NPM

1. 域名【v0.8 更新·V02.00 补充】：你已有 sixstars.cn（未备案）。⚠️ 注意：未备案 .cn 域名解析到国内 IP 的 80/443 端口会被运营商拦截——即便有公网 IP，端口转发也可能受影响。用非标端口（8443）可规避大部分检测，但不保险。但你的 stocktrading 已验证走 EdgeOne Pages 海外区（见分支 C / 附录 C），未备案域名展示通道已锁定这条路——静态展示不走端口转发，这个风险可规避。
2. 部署 DDNS-GO（Docker 容器，有网页界面）：自动检测公网 IP 变化，变了就自动更新域名解析。
3. 路由器端口转发：把路由器对外端口（如 8443）转发到 iMac 内网 IP 的 8443。⚠️ 不要转发 80/443——家宽基本封了 80。
4. iMac 固定内网 IP：在路由器给 iMac 绑定固定 IP（DHCP 静态分配），否则重启后端口转发失效。
5. NPM 反向代理 + HTTPS：外部访问 https://展示.你的域名.com:8443 → NPM → 转发到展示服务。
6. 优势：国内直连，速度最快，免费。

分支 B：无公网 IP

通道 1（操作）：Cloudflare Tunnel + Cloudflare Access

• 与分支 A 完全一样。这是关键——操作通道不依赖公网 IP，因为它走的是 iMac 主动出站连接。
• 在家用内网直连，在外走 Tunnel + Access 认证。
• 如果嫌 Tunnel 偏慢，有付费替代：frp 自建穿透（需租国内云服务器，约 30~60 元/月，国内速度快）或蒲公英等国内穿透服务。

通道 2（展示）：Cloudflare Tunnel + NPM

• 同样用 cloudflared 主动连出去，外部访问你的域名 → Cloudflare → tunnel → iMac。
• 免费、自带 HTTPS 和 DDoS 防护。
• 代价【v0.3 修改】：域名要托管在 Cloudflare（免费）；国内访问偏慢（实测延迟 300~800ms、速度 2~3MB/s，因为节点在境外）。展示类自用可接受，扛不住大流量。详见第四节核实。

双通道方案总结表【v0.5 新增】

结论：有没有公网 IP，你的核心诉求（随时随地操作 iMac）都能满足，方案完全一样。差别只在"对外展示"是快还是慢。所以你判断公网 IP 这件事，不卡操作通道，只影响展示体验——心理负担小很多。

分支 C：EdgeOne Pages 海外区（已验证·推荐用于静态展示）【V02.00 新增】

这是昨日 stocktrading.sixstars.cn 实际跑通的方式（见附录 C 完整复盘）。它不属于"有/无公网 IP"的分支，而是第三条路——静态内容托管在腾讯云 EdgeOne，不走 iMac。

工作原理（通俗版）：

1. 把要展示的静态文件（HTML/CSS/图片）上传到腾讯云 EdgeOne Pages 项目。
2. EdgeOne 给你一个 CDN 分发地址，内容存在云端节点上。
3. 腾讯云 DNS 加一条 CNAME（如 stocktrading → EdgeOne 节点），自动签发 HTTPS 证书。
4. 外部访问 https://stocktrading.sixstars.cn → 命中 EdgeOne 海外节点 → 返回内容。

为什么这条路已验证可行：

• 海外区添加自定义域名不要求 ICP 备案——你的 sixstars.cn 未备案也能绑。
• 国内经 CNAME 到 EO 海外节点可稳定访问（昨日 WebFetch 实测首页 + 子页均直开正常）。
• 内容在云端，iMac / MBA 完全不用开机——这和分支 A/B（需要 iMac 常开）本质不同。

适用场景：静态展示——项目展示页、报告站、个人主页、文档站等"放上去给别人看"的内容。

不适用场景：动态服务——需要数据库查询、实时交互、用户登录后个性化内容的，云端静态托管搞不定，得走 iMac 本地服务器（分支 A/B）。

和分支 A/B 的关系（关键认知）：

• 分支 A/B = "iMac 当服务器"，内容在 iMac 本地，iMac 必须常开 → 适合动态服务。
• 分支 C = "云端静态托管"，内容在腾讯云，iMac 不用开 → 适合静态展示。
• 两者不是二选一，而是分工：静态展示走 C（省心、免费、不依赖 iMac），动态服务走 A/B（需要本地算力）。

✅ V02.01 已解决：需求方拍板选方案 A（分工）——静态展示走 EdgeOne Pages，动态服务才走 iMac。详见第九节矛盾观察 4。

第 2 层：反向代理层 —— 统一入口 + HTTPS

为什么需要：你后面会跑多个展示服务，每个都开端口既难管又不安全。反向代理就是"一个门卫"，所有外部请求先到它，再按域名分发到内部服务。

推荐：Nginx Proxy Manager（NPM）

• 有完整的网页图形界面（适合你）
• 自动申请并续期 HTTPS 证书（Let's Encrypt）
• 按域名转发到不同容器
• 支持访问控制、基础认证

HTTPS 证书的坑：

• 因为 80 端口被封，NPM 默认的 HTTP-01 验证方式会失败
• 改用 DNS-01 验证：NPM 里填入域名服务商的 API Key，它通过 DNS 记录验证，不需要 80 端口
• 配置一次，证书自动续期，不用管
• 走 Cloudflare Tunnel 时，HTTPS 由 Cloudflare 自动处理，可跳过证书申请

访问方式：外部访问 https://展示.你的域名.com:8443 → NPM → 转发到内部容器的端口。

【v0.5 补充】NPM 只用于展示通道。管理界面（Portainer 9001、NPM 后台 9002 等）不挂公网域名——在家用内网 IP 访问，在外走 Tunnel + Access 认证。这样管理面和数据面彻底隔离，安全。

第 3 层：容器层 —— 一台机器跑多个服务

容器引擎：OrbStack（强烈推荐，替代 Docker Desktop）

• Apple Silicon 原生，比 Docker Desktop 轻量、快、省电
• 启动快，资源占用低
• 免费个人版即可
• 自带简洁的图形界面

容器管理：Portainer（Docker 容器，网页图形界面）

• 可视化管理所有容器：启动/停止/查看日志/查看资源占用
• 用 docker-compose 文件部署服务（复制粘贴别人写好的配置就能跑）
• 不用记命令行

为什么用容器而不是直接装软件：

• 隔离干净，删掉一个服务不影响其他
• 部署就是一段配置文件，可备份可复现
• 升级方便，社区有大量现成的镜像

第 4 层：服务层 —— 你想跑什么

按需部署，下面是几个常见场景，都是 Docker 一键起：

部署方式：写一个 docker-compose.yml，在 Portainer 里点"Stacks"上传即可，完全图形化。

第 5 层：监控层 —— 知道服务还活着

推荐：Uptime Kuma（Docker 容器，网页界面）

• 监控每个服务的 URL/端口是否在线
• 挂了立刻通知你（支持微信「Server酱」、邮件、钉钉、Telegram 等）
• 网页上看到每个服务的可用率统计
• 配置全图形化，点点就行

监控什么：

• 公网能否访问你的展示服务（从外部探测）
• iMac 本机的 CPU/内存/磁盘
• DDNS 是否还在正常更新
• Cloudflare Tunnel 是否在线

第 6 层：操作通道 —— Web 管理优先 + 远程桌面预案【v0.6 重写】

v0.5 这层从 Tailscale 改为 Cloudflare Access（远程管理升级为刚需）。v0.6 落实你的决策——形式 C：能用 Web 解决的优先 Web，Web 搞不定才动用远程桌面，做好扩展准备。并主动补一个必须知道的盲区。

你的决策：形式 C（先 A 后 B · 保留预案）

你确认【v0.6】：Web 能解决的优先考虑；除非 Web 搞不定，才用「在外直接访问 iMac 桌面操作鼠标」。设计原则——怎么更方便处理各种情况而优先设计，保留预案（完整定义见第二节关键设计原则）。

形式 A：Web 管理界面（主力 · 免费 · 覆盖 90% 场景）

Web 管理能干的事，按工具分：

• Portainer（管容器）：启动/停止/查日志/查资源占用/部署新服务/改配置/进容器终端
• NPM 后台（管域名转发）：加子域名、配 HTTPS 证书、改转发规则
• Uptime Kuma（管监控）：看在线状态、收告警
• Adminer（管数据库）：网页里增删改查数据、跑 SQL
• Nextcloud（管文件）：网页上传下载文件

通道：在家用内网 IP 直连（零延迟）；在外走 Cloudflare Tunnel + Access 邮箱认证（延迟 300~800ms，点点按按完全够用，免费）。

Cloudflare Access 的工作原理（邮箱验证码零信任认证，外面的人连登录页都看不到）v0.5 已说明，此处不再重复。

⚠️ 主动补的盲区：管理面「同生共死」兜底问题【v0.6 新增】

Web 管理有个绕不开的盲区，必须提前讲清楚——管理工具本身也跑在 iMac 上。

打个比方：你想修车，但修车工具全锁在车后备箱里。车正常时没问题；可一旦车抛锚打不开门，你连工具都拿不到——工具和车一起趴窝了。

对应到你的情况：

• Portainer 是个容器，它管其他容器。但 Portainer 自己也跑在 OrbStack（容器引擎）上。
• 如果 OrbStack 整个挂了，Portainer 也跟着起不来——这时你连管理界面都进不去，干瞪眼。
• 这叫「管理面和被管理面同生共死」：管理工具跑在被管理的环境里，环境挂了管理也挂了。

Web 管理够不着的场景（这些正是形式 B 的真实价值）：

结论：形式 B（远程桌面）不是"多余"，是"备用钥匙"——平时不用，但 Web 失灵时能直接操作 iMac 系统层救场。所以预案必须准备好，哪怕大概率用不上。

形式 B：远程桌面（预案 · 按需启用）【v0.6 细化】

触发条件（出现这些情况时启用形式 B）：

• OrbStack/容器引擎挂了，Web 管理进不去
• 要操作 macOS 系统层（更新、装软件、改系统设置）
• 排查硬件/网络问题
• 其他 Web 管理够不着的场景

为什么远程桌面不走 Cloudflare Tunnel？ 远程桌面（看屏幕、动鼠标）对延迟极敏感。Cloudflare Tunnel 走境外节点，300~800ms 延迟下鼠标操作有明显卡顿——能用但不舒服。所以预案优先选国内方案（延迟低、体验好）。

预案推荐：

说明【v0.6】：向日葵/ToDesk 是国内商业远程桌面服务，免费个人版够用。代价是连接要过它们的服务器（数据过第三方），且免费版有限速。但作为"偶尔救场"的预案，这个代价可接受——毕竟你不会天天用远程桌面，主力还是 Web 管理。

扩展准备（现在不装，但要知道怎么做）：

1. 现在就能做的零成本预留：iMac 系统设置 → 通用 → 共享 → 打开「屏幕共享」。开了不影响什么，需要时直接能用。
2. 真需要远程桌面时：iMac 和 MBA 各装一个向日葵（或 ToDesk）客户端（5 分钟），登录同一账号，就能在外连 iMac 桌面。
3. 不提前装客户端的理由：大概率装了也用不上几次（Web 管理覆盖 90%+ 场景）。客户端等需要时再装，5 分钟的事，没必要为低频功能提前占资源。

我的建议：iMac 的「屏幕共享」开关现在就打开（零成本预留）。向日葵/ToDesk 客户端等真需要时再装。先用 Cloudflare Tunnel + Access 跑 Web 管理，实际用了发现不够，再启用形式 B——到时 5 分钟就能接入，不会卡住你。

操作通道总结

第 7 层：安全

家用服务器暴露在公网，安全必须做：

1. 只暴露反向代理端口（8443），数据库、管理面板等端口一律不转发到公网。【v0.5 补充】管理界面走 Tunnel + Access，不挂公网域名。
2. macOS 防火墙开启：系统设置 → 网络 → 防火墙，只允许必要服务。
3. 路由器防火墙保留，只开端口转发需要的端口。
4. 所有服务设强密码，尤其 NPM、Portainer、数据库。
5. 定期更新：OrbStack、容器镜像、macOS 系统更新。
6. SSH 关闭密码登录【v0.3 修改】（如果开了 SSH 的话），只用密钥；或者干脆不开 SSH，全走图形界面 + Tunnel。
7. Cloudflare Access 认证【v0.5 新增】：管理界面必须经过邮箱验证码认证，不裸暴露。

端口规划参考（方便记忆）【v0.2 新增】

按"千位区段"分类，首位数字代表用途，好记：

记忆口诀：8 对外、9 管理、5 应用、4 数据库。

对外其实只需记一个端口：8443。所有外部展示访问都从 NPM 的 8443 进来，再按子域名分发到内部服务。管理界面（9xxx）只通过内网或 Tunnel 访问，外面根本碰不到。

端口候选：若 8443 不顺手，也可选 9443、8800 等，避开 80/443/22 等常用且可能被封的端口。建议固定一个别老换。

四、费用与网络兼容性核实（逐项核实）【v0.3 重写】

你问得对——"免费"和"国内能用"是两回事。下面每个工具都核实了三件事：是否免费、国内网络能否直接用、有什么坑。核实时间 2026-07，政策可能变动，以官方为准。

4.1 工具逐项核实表

4.2 总成本明细

基础方案总成本 = 域名钱 + 电费，一年约 100~300 块，比腾讯云便宜很多。 唯一可能额外花钱的环节：操作通道嫌 Cloudflare Tunnel 慢，换国内穿透方案（月费 30~60）。先用免费的，实际体验后决定。

4.3 需要警惕的工具

⚠️ Cloudflare Tunnel + Access：免费，但国内偏慢

• 免费档功能够用，不限流量、不限时长，自带 HTTPS + DDoS 防护 + 零信任认证。
• 国内访问延迟 300~800ms，实测速度 2~3MB/s（节点在境外）。
• Web 管理界面（Portainer 等）：完全够用，点点按按不受影响。
• 远程桌面（VNC/屏幕共享）：可能略卡，看你对流畅度要求。
• 展示类服务：自用、给少数人看够用；不适合流媒体、大文件下载、高并发。

【v0.5 修正】之前这里还列了 Tailscale 的警惕项。v0.5 已用 Cloudflare Access 替代 Tailscale 作为操作通道方案，所以 Tailscale 的风险不再适用。Cloudflare Access 和 Tunnel 共用同一套境外基础设施，延迟特性一致。

4.4 一句话总结

• 纯局域网用（家里同 WiFi）：所有工具免费、纯本地、零境外依赖。
• 操作通道（MBA 远程操作 iMac）：Cloudflare Tunnel + Access，免费，Web 管理够用，远程桌面可能略卡。
• 展示通道 - 有公网 IP：DDNS + 端口转发，全链路国内，速度最好，零额外成本。
• 展示通道 - 无公网 IP：Cloudflare Tunnel，免费但偏慢，展示类自用可接受。
• 唯一可能额外花钱：操作通道嫌慢，换国内穿透方案（月费 30~60）。

五、实施步骤（分阶段）

⏸️ 当前阶段：需求基本定稿，进入试水部署。 以下步骤为方案确定后的实施顺序；每步傻瓜化细节见模拟执行手册 imac-server-dryrun.md。静态站试水（分支 C·EdgeOne 海外区）为当前最优先落地项。

阶段 0：准备 + 判断网络（30 分钟）

• [ ] 确认 iMac 芯片型号（左上角苹果菜单 → 关于本机）
• [ ] 判断有没有公网 IP（见第三节：对比 ip138.com 和路由器 WAN IP）
• [ ] 路由器里给 iMac 绑定固定内网 IP
• [x] ~~买一个域名~~ 已完成（v0.8）：已有 sixstars.cn（未备案），stocktrading 子域名已跑通。需确认 sixstars.cn 是否已托管到腾讯云 DNS——V02.00 已查证 stocktrading.sixstars.cn 走腾讯云 EdgeOne Pages（海外区）（非 Cloudflare），域名 DNS 在腾讯云；若尚未迁到腾讯云 DNS 需先迁移，否则 EdgeOne 的 CNAME 加不上。

阶段 1：基础环境（1 小时）

• [ ] 装 OrbStack
• [ ] 起 Cloudflare Tunnel（cloudflared），打通操作通道
• [ ] 配置 Cloudflare Access，给管理界面加邮箱认证
• [ ] 验证：MBA 在外面（4G）能通过 https://manage.你的域名.com 访问，且需邮箱验证码

阶段 2：展示通道（1 小时）

• [ ] 有公网 IP：起 DDNS-GO 配域名解析 + 路由器端口转发 8443
• [ ] 无公网 IP：在 Cloudflare Tunnel 里加展示服务的路由
• [ ] 用 Portainer 起 NPM
• [ ] 起一个测试容器（nginx 欢迎页），配展示子域名转发
• [ ] 验证：手机 4G 访问 https://展示.你的域名.com:8443，能看到页面

阶段 3：监控（30 分钟）

• [ ] 起 Uptime Kuma
• [ ] 配置监控你的展示服务 + Tunnel 在线状态
• [ ] 配置告警通知（推荐 Server酱 → 微信）

阶段 4：按需上服务

• [ ] 想跑什么展示服务就找对应的 docker-compose，丢进 Portainer
• [ ] 在 NPM 里加一条子域名转发
• [ ] 完事

六、关键注意事项

1. 80/443 端口

国内家宽普遍封 80 端口（部分地区封 443）。所以对外用非标准端口（如 8443）。缺点是访问时要带端口号，但自用完全够。

2. 上行带宽

家庭宽带上行通常只有下行的 1/5~1/10。展示服务吃上行，自用几个人访问毫无压力，但别指望扛住高并发。

3. 稳定性

• 断电恢复（重要修正）：Apple Silicon iMac 断电恢复供电后不会自动开机，pmset autorestart 在 Apple Silicon 上无效/被忽略（已实测核实）。因此不能用"断电自启"思路，改为：① UPS 必选——扛短暂停电（市电闪断/跳闸），并在「系统设置 → 电池/能源 → UPS」设"电量低于 X% 时自动干净关机"以保护 SSD/文件系统；② 长停电恢复开机靠远程桌面引导或请人按电源键（iMac 不自愈），该动作纳入操作通道远程桌面预案；③ 智能插座只能"远程通电"，不能让 Mac 开机，单独不够；④ 架构级兜底：把 7×24 刚需服务迁到支持"断电自启（AC Recovery）"的 x86 小主机/NAS。详见「十二、电源与容量扩展预案」。
• 自动启动服务：前提是一台已开机的 iMac。OrbStack 设开机自启，所有容器设 restart: always，开机后自动恢复服务。
• IP 变更：DDNS-GO 会自动处理（有公网 IP 时）；Cloudflare Tunnel 不受 IP 变化影响。

4. 备份

• 重要数据（数据库、配置文件）定期用脚本打包，可同步到网盘或另一台机器。
• docker-compose 文件存好，换机器能快速重建。
• macOS 自带 Time Machine 也可以用。

5. 运营商政策

• 部分运营商对家宽建站有监管，自用小流量一般没事，但别做大流量公开服务。

七、和腾讯云的真实差距

结论：自用、学习、展示炫耀，iMac 方案完胜（省钱 + 数据自主）；如果要扛正式业务、对可用性要求高，还是上云。你的博士后管理业务线上化如果是单位正式系统，建议核心数据/正式服务上云，iMac 做开发测试 + 个人工具 + 备份。

八、需求演进日志（问答记录）

本节按时间顺序记录每次「我问 → 你答 → 解释」的打磨过程。新问答追加在末尾。

【07-16 07:16】初始需求 → 出方案

• 我问：想把家里一台闲置的 iMac 改造成通用服务器，类似于腾讯云对外提供服务，需要如何搭配？
• 你答：先澄清家用与云的本质差距（公网 IP、对称带宽、电力冗余），再给出七层分层方案。
• 解释：家用 iMac 改服务器机器够用，卡脖子的是网络。先理解差距，方案才贴合实际。

【07-23 07:30】公网 IP 认知修正 + 端口规划

• 我问：没搞清楚什么是公网动态 IP，也许就没有自己的 IP，请修正方案；另外用非标准端口，能否提供端口号使用区间供我选择。
• 你答：网络层改为"先判断有无公网 IP"的双方案；新增端口规划表（8 对外 / 9 管理 / 5 应用 / 4 数据库）。
• 解释：有没有公网 IP 是分水岭。端口按千位区段分类便于记忆，对外只需记 8443。

【07-23 07:40】费用与网络兼容性核实

• 我问：你提到的所有工具都是免费而且直接可以依赖国内网络或局域网实现联通联调吗？涉及费用的地方请核实清楚并在文档中描述。
• 你答：重写第四节为「逐项核实表」，指出 Tailscale 和 Cloudflare Tunnel 虽免费但依赖境外服务、国内体验有坑。
• 解释："免费"和"国内能用"是两回事。纯本地工具零境外依赖；两个境外依赖工具是国内使用的隐性成本。

【07-23 07:44】补认知盲区 + 转入打磨模式

• 我问：先完善需求和做准备，暂时不具体实施；根据我的想法反复打磨可行方案（最好有预案）；加强对认知盲区的理解，多做通俗化解释。
• 你答：梳理 5 大认知盲区；列 2 个待决策点及各自预案。
• 解释：认知盲区不补，装完才发现不对劲就晚了。先打磨需求、补盲区、配预案，全部明确后再动手。

【07-23 07:52】确立文档驱动打磨机制

• 我问：建立打磨需求的大原则——每次问答在文档内做明确标注 + 版本控制；每次反馈给最新版；发现矛盾及时提醒并给选择建议。
• 你答：文档新增版本控制块、决策状态总览、需求演进日志、矛盾观察清单；回溯前几轮已发生的问答。
• 解释：文档驱动比口头来回可靠，矛盾早发现早决策。

【07-23 08:05】定位澄清 + 双通道双分支重构

• 我问：解释第一个张力——实际需求是「MBA 随时随地稳定操作 iMac」+「对外仅展示内容」，自用为主兼带展示。按"自用+预留扩展"推进。公网 IP 有无按分支分别处理，在需求中明确。
• 你答：① 矛盾观察 1 标记已解决（定位=自用+预留扩展）；② 网络层重构为「双通道+双分支」——操作通道（MBA→iMac）和展示通道（iMac→外部）独立设计，有无公网 IP 两条路均写明；③ 第 6 层由 Tailscale 改为 Cloudflare Tunnel + Access（远程管理升级为刚需，用零信任认证替代设备组网）；④ 新增矛盾观察 2（操作形式待明确：远程桌面 vs Web 管理界面）。
• 解释：你的核心诉求其实是两条独立通道。操作通道不依赖公网 IP（走 iMac 主动出站），所以有无公网 IP 只影响展示通道——心理负担大减。远程管理从"可选项"修正为"刚需"，用 Cloudflare Access 替代 Tailscale 既满足需求又避免境外组网的不稳定性。

【07-23 08:19】操作形式确认 + 方便优先原则 + 同生共死盲区

• 我问：操作选择形式 C，先按形式 A 做，需要时再加形式 B，做好扩展准备。能用 Web 解决的优先考虑；除非不能，才用「在外直接访问 iMac 桌面操作鼠标」。考虑原则：怎么更方便处理各种情况而优先设计（保留预案）。
• 你答：① 矛盾观察 2 标记已解决（形式 C 确认）；② 新增设计原则「方便优先·保留预案」写进关键设计原则；③ 第 6 层重写为「Web 管理 + 远程桌面预案」；④ 主动补盲区「管理面同生共死」——Portainer 是容器跑在 OrbStack 上，底座挂了管理也挂了，这正是形式 B 的真实价值；⑤ 远程桌面预案细化推荐国内方案（向日葵/ToDesk，免费版够），不走 Cloudflare Tunnel（延迟敏感）；⑥ iMac「屏幕共享」开关作为零成本预留现在就开。
• 解释：Web 管理覆盖 90%+ 场景且对延迟宽容（免费够用），所以做主力。但它有"同生共死"盲区——管理工具跑在被管理环境里，环境挂了管理也挂了。远程桌面就是这种时候的"备用钥匙"，预案用国内方案保证延迟体验，平时不装客户端、需要时 5 分钟接入，符合"方便优先·保留预案"原则。

【07-23 08:34】附加问题：昨日任务能否沿用 + WorkBuddy 复用机制认知

• 我问：昨天做的一个任务的实现过程和各种调用打通环节，今天这个任务能直接沿用吗？（作为使用 WorkBuddy 的附加问题存在文档最后）
• 你答：① 搜索昨天（2026-07-22）对话记录，未找到相关任务，需需求方确认具体内容；② 新增附录 A「使用 WorkBuddy 的认知与复用机制」，通俗讲解 WorkBuddy 的四层存储（全局共享 / 项目专属 / 会话专属 / 历史可检索）与跨任务复用规则；③ 给出"昨天留下什么 → 今天能否沿用"的对照表；④ 建议主动沉淀（工作流存技能、偏好存记忆）让复用最大化。
• 解释：这是个关于 WorkBuddy 使用本身的认知盲区——不同"东西"存在不同地方，有的跨任务有的不跨。搞清楚这个，才知道昨天的成果今天还在不在、要不要重做。也呼应"方便优先"原则：让该复用的自动跟着走，该沉淀的主动存下来。

【07-23 08:58】昨日任务具体化 + 未备案域名联动 + projects 三层网页设计

• 我问：昨天用未备案域名 sixstars.cn 设置了访问页 stocktrading.sixstars.cn，这个配置过程今天能直接调用吗？想再设置 projects.sixstars.cn，三层结构：首页罗列项目列表和启动时间，第二层按项目管理理论设计分支（需求、工具……），第三层具体内容。最简单设计，简约经典，体现个人标记"需求方（欣欣向荣的欣）"。
• 你答：① 昨日任务具体化——已有 sixstars.cn（未备案），stocktrading 子域名已跑通，域名环节标记完成；② 配置流程可复用（同域名不同子域名，DNS 在同一后台），但"直接调用"取决于是否沉淀成技能，建议存成用户级技能；③ 新增矛盾观察 3——未备案 .cn 域名对展示通道方案 A（端口转发）的影响，未备案域名天然偏向 Cloudflare 方案；④ 新增附录 B「projects.sixstars.cn 三层网页设计方案」——三层结构 + 简约设计 + "欣欣向荣"个人标记；⑤ 更新附录 A，昨日任务具体化并给出复用判断。
• 解释：你的域名未备案是个关键信息——它影响展示通道走哪条路。未备案 .cn 解析到国内 IP 的 80/443 会被拦，而 Cloudflare 走境外节点天然规避备案要求。这正好解释了 stocktrading 为什么能访问（大概率走 Cloudflare）。projects.sixstars.cn 的配置流程和 stocktrading 本质一样，可以复用。三层结构按精简版项目管理理论设计，简约风格配"欣欣向荣"绿色意象。

【07-23 10:05】个人标记规范写法确立（全局）

• 我问：在用户画像里增加一个全局的内容，个人标记设定为：大欣，欣欣向荣的欣（不要多字少字，也不要随意改变）。
• 你答：① 写入全局用户级记忆 ~/.workbuddy/MEMORY.md，新增「个人标记（身份）」章节，明确规范写法为「大欣，欣欣向荣的欣」，并标注"不要多字、少字，也不要随意改写"的硬约束；② 同步修正 iMac 方案文档附录 B 两处写法不一致——第710行原为「需求方」+「欣欣向荣」分开写、第736行原为括号格式「需求方（欣欣向荣的欣）」，统一改为规范写法；③ 个人标记为跨项目通用设定，未来任何项目涉及署名/网页标记/文档落款均以此为准。
• 解释：需求方对个人标记的精确写法有明确要求——逗号分隔、不加括号、不多字少字。这是身份标识，写法必须统一稳定，不能每次随意变体。此前附录 B 里出现了两种不一致的写法（拆分式 + 括号式），本次一并纠正。规范写法同时沉淀到全局记忆，确保跨项目自动带出，不用每次重复声明。

【07-23 10:14】个人落款规范确立（全局）

• 我问：所有个人行为产生的资料里，都在最底部固定位置设定：sixstars.cn ☆ 大欣，欣欣向荣的欣 ☆ 「具体时间：年月日-时分秒」（☆ 可根据页面显示需要选择实心/空心/颜色；具体时间就是最终定稿的时间，如直接显示 2026.07.23-10:13:34）。
• 你答：① 写入全局用户级记忆 ~/.workbuddy/MEMORY.md，新增「个人落款规范（资料底部固定）」章节，明确格式为 sixstars.cn ☆ 大欣，欣欣向荣的欣 ☆ <定稿时间>；② 定稿时间格式 = 年.月.日-时:分:秒，每次更新资料同步刷新为当前版定稿时间；③ ☆ 样式按载体灵活——纯文本/Markdown 用 ☆ 字符，网页用 CSS 控实心/空心/颜色；④ 本文档底部签名改用需求方规范落款，替换原"文档维护：Infrastructure Maintainer"行（版本控制信息已在顶部版本控制块完整保留，底部不再重复）。
• 解释：落款规范是个人标记在"资料底部署名"场景的具体格式，与 v0.9 确立的个人标记规范写法一脉相承。三要素（域名 + 个人标记 + 定稿时间）构成完整落款，缺一不可。域名 sixstars.cn 作为个人域名标识纳入落款，呼应 v0.8 的域名信息。定稿时间随每次更新刷新，让每版资料都有可追溯的时间锚点。

【07-23 10:24】版本号命名规范确立（全局）

• 我问：版本中的 v 改用 V，后面的版本号采用大改+1，小改用二级 .01~.99。区分"大改"（重大功能调整、结构调整、增减内容等）和"小改"（对既定内容修修补补、进一步简化或细化等）。如果不确定，反馈给需求方由其选择确定。
• 你答：① 版本号规范写入全局记忆（跨项目通用）——V 大写、主版本号=大改两位补零、二级版本号=小改 .01~.99、大改后归零、初版 V01.00；② 对历史 v0.1~v0.10 做大改/小改分类（v0.1~v0.8 涉及结构调整/功能调整/内容增减=大改、v0.9~v0.10 为修修补补=小改）；③ 就"当前版本号定多少"反馈需求方——给出三选项（V01.00 新起点 / V08.03 继承·小改 / V09.00 继承·大改）；④ 需求方选定择 V01.00 新起点：历史 v0.1~v0.10 保留原编号不继承进度，自本次起新规范从 V01.00 干净起步；⑤ 需求方写法为 V01.00（主版本号两位补零），比 V1.00 更整齐——与二级版本号两位对齐，全局记忆同步修正为主版本号两位补零。
• 解释：版本号规范是文档迭代管理的底层规则。大改/小改的区分让版本号自带"变更性质"信息——看版本号就知道这轮是结构调整还是修补细化，不用翻变更记录。新起点 V01.00 的选择意味着：历史演进已在变更记录表详细留存，新规范从 V01.00 干净起步，主版本号不会一上来就到 08。主版本号两位补零（V01 而非 V1）与二级两位对齐，视觉更统一。往后每次迭代：大改→主版本号+1（V02.00）、小改→二级+1（V01.01）。

【07-23 10:36】昨日 stocktrading 走通方式实地查证 + 文档结构补充

• 我问：你在本机的 workbuddy 目录里的昨天建的项目文件夹 sinopec_analysis 里找找 stocktrading 走通的方式，补充到当前需求文档的某个位置上，做好文档内容的结构设计。
• 你答：① 实地查证昨日项目 /Users/sixstars/WorkBuddy/2026-07-22-08-16-52/sinopec_analysis/——读 deploy_reports.sh、.bin/cloudflared、工作日志 2026-07-22.md，确认 stocktrading.sixstars.cn 实际走的是腾讯云 EdgeOne Pages（海外区），不是 Cloudflare（之前 v0.8 推测"大概率走了 Cloudflare"有误，本次纠正）；② 新增附录 C「昨日 stocktrading 走通方式复盘（已验证链路）」——完整记录技术链路：域名在腾讯云注册（未备案）→ EdgeOne Pages 海外区项目 stocktrading → 腾讯云 DNS 加 CNAME → 自动 HTTPS → EdgeOne CLI 自动部署（deploy_reports.sh，关键参数 -a overseas）；③ 矛盾观察 3 标记已解决——已验证方案 = EdgeOne Pages 海外区（未备案可用、不需公网 IP、不需 iMac 常开）；④ 新增矛盾观察 4——EdgeOne Pages 云端静态托管 vs iMac 本地服务器的架构选择；⑤ 网络层展示通道新增「分支 C：EdgeOne Pages 海外区（已验证·推荐）」；⑥ 附录 B 修正复用方式（projects.sixstars.cn 部署复用 EdgeOne Pages）；⑦ 版本 V01.00 → V02.00（大改：结构调整 + 内容增减）。
• 解释：这是本轮最重要的认知修正——之前一直推测 stocktrading 走 Cloudflare，实际走的是腾讯云 EdgeOne Pages 海外区。EdgeOne 是腾讯版 Cloudflare，海外区添加自定义域名不要求 ICP 备案，国内经 CNAME 到 EO 海外节点可稳定访问。更关键的洞察：EdgeOne Pages 是云端静态托管（内容传到腾讯云，iMac 不需要常开），这和"iMac 当服务器对外提供服务"（内容在 iMac 本地，必须常开）是两种完全不同的架构。对于 projects.sixstars.cn 这种"展示内容"：如果是静态展示，直接复用 EdgeOne Pages 即可，根本不需要 iMac 当服务器；如果需要动态后端（数据库、实时交互），才需要 iMac。这个架构选择是新矛盾观察 4 的核心，必须需求方认知后拍板。

【07-23 10:48】矛盾观察 4 拍板：静态上云、动态留本地

• 我问：（无新提问——基于 V02.00 查证结果，需求方对矛盾观察 4 做认知 + 拍板）
• 你答：① 画架构对比图通俗讲解「静态展示 vs 动态服务」——静态展示走 EdgeOne（内容在云端 CDN，iMac 不用开），动态服务走 iMac（内容在本地，必须常开）；② 给三个选项（A 分工 / B 全走 iMac / C 全走云端）+ 推荐 A；③ 需求方拍板选 A（分工）；④ 矛盾观察 4 标记已解决；⑤ 展示通道架构决策状态 🟡→🟢；⑥ iMac 服务器定位重新明确——静态上云、动态留本地，iMac 只管动态服务 + 操作通道 + 存储；⑦ 整体架构图更新——展示通道标注「静态走 EdgeOne / 动态走 iMac」；⑧ 版本 V02.00 → V02.01（小改：解决现有矛盾 + 更新定位，无新增结构）。
• 解释：这个决策把 iMac 服务器的定位彻底明确了。之前一直把"iMac 当服务器"理解为"什么内容都放 iMac"，现在分清了——静态展示（提前写好的 HTML 页面，放上去给人看）上云更省心（免费、不用常开、CDN 还快）；iMac 的真正价值在于跑动态服务（需要后端算力、数据库、实时交互的东西）+ 操作通道（MBA 随时随地操作）+ 文件存储。projects.sixstars.cn 大概率是静态展示（项目列表 + 详情页），直接复用 EdgeOne 即可。这意味着矛盾观察清单 4 条全部解决，核心架构决策全部明确，方案接近定稿。

【07-23 10:56】新增全局工作方式规范：文字风格积累 + 主动追问

• 我问：你注意积累我的文字表达方式，久了，后续会让你模仿我来整理很多内容表达；在对话中如果出现我描述不清不准确的地方，建议你也让我做进一步的解释，这样可以达到我们彼此的充分沟通。（这个加入全局需求）
• 你答：① 写入全局用户级记忆 ~/.workbuddy/MEMORY.md，在「工作方式（执的规矩）」章节新增"文字风格积累 + 主动追问"条目（跨项目通用）；② 两条规范——a) 注意积累需求方的文字表达方式（用词习惯、句式偏好、表达节奏），久了能模仿需求方风格整理内容表达，而非一律用自己的口吻；b) 对话中出现需求方描述不清、不准确的地方，主动让需求方做进一步解释（而非自行猜测或草率回应），以达到充分沟通；③ 同步记录到本项目需求演进日志；④ 版本 V02.01 → V02.02（小改：补充工作方式规范，无结构调整）。
• 解释：这是协作沟通层面的长期规范，和需求方此前确立的文档驱动打磨机制（v0.4）、版本号规范（V01.00）、个人标记/落款规范一脉相承——都是在定义"我们怎么一起干活"。第一条（积累文字风格）意味着我以后整理内容时，会逐步从"用我自己的表达习惯"过渡到"贴近需求方的表达习惯"，让产出更像需求方自己的东西，而非 AI 代笔的痕迹。第二条（主动追问）是对文档驱动机制的补充——之前只要求"发现矛盾时提醒"，现在扩展到"描述不清时也主动追问"，确保沟通充分、不因猜测而跑偏。两条均跨项目通用，不限于 iMac 方案。

【07-23 11:16】附录 B projects 网页设计细化：留言板 + 自适应 + 分页 + 字体

• 我问：聊岔掉了。现在说说 projects 网页设计的细节：三层结构是确定的，在首页右侧增加一个简易的留言板功能；另外，为了保障尽可能少的使用上下左右滚动条的出现，要求网页设计上要符合目前主流的浏览器，PC 端和手机端都要考虑自适应，尽可能对越来越多的内容采用分页处理；文字的对外表现，替我选一个能够体现计算机专业的字体样式。
• 你答：① 三层结构确定不变；② 首页布局改为左列表 + 右留言板（手机端自适应堆叠）；③ 留言板是动态功能，按 V02.01 分工原则走云端轻量后端（不放 iMac），方案待需求方拍板——推荐 Twikoo（腾讯云函数），备选 Giscus / 先不做；④ 自适应要求写入 B.3——CSS media queries + flexbox/grid，兼容 Chrome/Safari/Firefox/Edge，手机端堆叠布局；⑤ 分页要求写入——首页项目列表分页 + 第三层长内容分页，替代无限滚动，减少竖向滚动；横向滚动尽量避免；⑥ 字体选定——标题/代码/强调用 JetBrains Mono（等宽，计算机专业视觉符号），中文正文用思源黑体（可读性），自托管不依赖 Google Fonts；⑦ 版本 V02.02 → V02.03（小改：附录 B 细化，三层结构未变）。
• 解释：这次细化把 projects 网页从"框架设计"推进到"可实施细节"。几个关键判断：a) 留言板的归属——它是动态功能（要存数据），但太轻量不值得为它开 iMac，所以走云端轻量后端（云函数），这和 V02.01 拍板的"静态上云、动态留本地"分工是一致的——留言板属于"轻量动态"，归云端而非 iMac；b) 字体的专业感——需求方要"体现计算机专业"，等宽字体（monospace）是最直接的视觉符号，JetBrains Mono 是当前程序员圈最流行的等宽字体之一，比老派的 Courier 新潮、比 Cascadia 通用；中文配思源黑体保证可读性；c) 减少滚动条——核心思路是"分页替代无限滚动 + 响应式避免横向滚动"，单页内容控制在一屏可览核心。留言板方案需需求方拍板后才能定具体实现，但不阻塞静态主体（先做页面，留言板后接）。

【07-23 11:37】附录 B 继续细化：网页标题 + 遵纪守法提示 + 留言板场景明确

• 我问：Twikoo 和 Giscus 具体什么区别？简易留言板只是用于访客的初次留痕。另外，网页的标题不要用重复的信息，改成：内容分享（仅供学习交流）；另外增加遵纪守法的小字提示。
• 你答：① 通俗讲解 Twikoo vs Giscus 区别——Twikoo 是自部署小后端（云函数+数据库），访客直接输入就能留言、不需任何账号、数据自己掌控；Giscus 借用 GitHub Discussions 当存储，访客必须有 GitHub 账号才能留言、零部署；② 结合需求方说的"访客初次留痕"场景，Giscus 基本排除（普通访客无 GitHub 账号），推荐 Twikoo；③ 网页标题（浏览器 <title>）改为「内容分享（仅供学习交流）」，不与顶部个人标记/底部落款重复——三者各司其职；④ 新增遵纪守法小字提示（落款上方），有留言板时尤必要（用户生成内容的国内合规要求）；⑤ 画 projects 首页设计草图（PC 左右布局+手机堆叠+字体示意+翻页器+留言板+落款）；⑥ 版本 V02.03 → V02.04（小改：继续细化附录 B）。
• 解释：需求方"访客初次留痕"这一句场景描述很关键——它直接把 Giscus 排除了。Giscus 适合"技术圈朋友互相讨论"的场景（大家都有 GitHub 账号），但不适合"普通访客留个痕"（朋友、同事未必有 GitHub 账号）。Twikoo 的优势正在于此：访客打开网页、输入文字、点发送，完事——零门槛。网页标题改成"内容分享（仅供学习交流）"是好的——既给站点定了性（这是分享性质的、非商业），又避免了个人标记在标签页/顶部/底部三处重复。遵纪守法提示在国内有用户生成内容的站点上是基本操作，先写进设计免得后期补。

【07-23 11:41】留言板方案确认：Twikoo

• 我问：（确认留言板方案选哪个）
• 你答：需求方确认选 Twikoo。
• 解释：留言板方案锁定。Twikoo 部署到腾讯云 CloudBase（云函数 + 数据库），访客零门槛留言、数据在需求方自己手里、和 EdgeOne 同属腾讯生态、未备案域名走海外区函数可用。这步在静态页做好之后再接——先做三层结构 + 自适应 + 分页 + 字体的静态主体，Twikoo 后接，不阻塞上线。至此 projects 网页设计的待确认项仅剩：① 第二层 5 个分支是否够用；② "欣欣向荣"视觉标记偏好方向。

【07-23 11:46】首页邮箱（防爬）+ 全站实时数码时钟

• 我问：在首页特定位置增加：个人邮箱 sixstars@qq.com（为防止暴露在公网遭垃圾邮件骚扰，请采用技术手段处理）；另外，所有页面右上角都增加一个服务器相关的显示日期和时间（实时的，数码时钟）。
• 你答：① 邮箱防爬——采用 JS 动态拼接方案：HTML 源码里不写完整邮箱字符串，用 JavaScript 在页面加载时拼接（'sixstars' + '@' + 'qq.com'）再写入页面 + 动态生成 mailto: 链接。原理：垃圾邮件爬虫只读 HTML 源码、不执行 JS，所以抓不到完整地址；访客打开网页时 JS 正常执行，邮箱正常显示可点击——体验零损失、防护到位。备选方案是邮箱做成图片（最彻底但牺牲点击便利），作为兜底。邮箱位置建议放首页顶部个人标记附近，与右侧留言板形成"留痕 + 私信"两种联系途径。② 实时数码时钟——所有页面右上角通用组件，显示日期+时间（2026-07-23 11:46:55 格式），JetBrains Mono 字体（数码管质感、呼应计算机专业），前端 JS 每秒刷新。③ 歧义标注——"服务器相关"含义存两种理解（A=显示当前北京时间实时时钟 / B=显示 iMac 运行状态），默认按 A 设计（纯前端无后端依赖，不阻塞），B 作为后续可选扩展，待需求方确认。版本 V02.05 → V02.06（小改：细化附录 B）。
• 解释：邮箱防爬的核心认知点是"爬虫读源码不执行 JS"——这是前端反爬的基本原理，JS 动态拼接是最主流、体验最好的方案（比邮箱图片方便、比 CSS 混淆可靠）。需求方主动提"采用技术手段处理"说明有安全意识，这里把方案和原理讲清楚，实施时照着写就行。数码时钟的歧义点按"主动追问"规范标出——如果需求方要的是 iMac 运行状态（理解 B），那会和静态站定位冲突（iMac 不用开就没有状态可显示），需要重新设计；但更可能是理解 A（就是个右上角实时时钟，"服务器相关"是风格描述）。先按 A 做不阻塞，等需求方一句话确认即可。

【07-23 11:52】数码时钟含义确认：理解 A（实时时钟）

• 我问：（确认"服务器相关的显示日期和时间"是哪种意思）
• 你答：需求方确认选理解 A——就是右上角实时数码时钟，显示当前日期+时间（北京时间），"服务器相关"指风格气质。
• 解释：歧义解决，数码时钟方案彻底定稿——纯前端 JS，显示 年-月-日 时:分:秒，JetBrains Mono 字体，每秒刷新，无后端依赖。理解 B（iMac 运行状态）不采用，因与静态站定位冲突。至此 projects 网页设计的待确认项仅剩：① 第二层 5 个分支是否够用；② "欣欣向荣"视觉标记偏好方向。

【07-23 11:57】页面顶部调整：去个人标记，改主副标题

• 我问：网页顶部，去掉个人标记的内容，改成：「主标题」：内容分享，「副标题」：仅供学习交流。
• 你答：① 页面顶部去掉个人标记「大欣，欣欣向荣的欣」，改为：主标题「内容分享」+ 副标题「仅供学习交流」；② 个人标记从顶部移除，仅在底部落款保留（sixstars.cn ☆ 大欣，欣欣向荣的欣 ☆ 定稿时间）——顶部不再放个人标记；③ 标签页标题（<title> = 内容分享（仅供学习交流））与顶部主副标题呼应，同一套文案，站点定性一致；④ 邮箱位置描述同步更新（原"个人标记附近"改为"主副标题下方"）；⑤ B.3 个人标记位置说明更新——标注顶部已移除、仅底部保留；⑥ 版本 V02.07 → V02.08（小改：调整顶部内容，无结构变动）。
• 解释：这个改动和 V02.04 的决策一脉相承——V02.04 把标签页标题改成「内容分享（仅供学习交流）」是为了"避免个人标记在标签页/顶部/底部三处重复"，现在需求方更进一步，直接把顶部个人标记也去掉，改用主副标题。这样页面三处变成：标签页 = 站点定性、顶部 = 主副标题（和标签页呼应）、底部 = 落款署名（带个人标记）。个人标记只在底部保留，不再散落在多处。需提醒需求方：顶部去掉个人标记后，访客一进来看到的是"内容分享/仅供学习交流"，不知道这是谁的站——要滑到底部才看到"大欣，欣欣向荣的欣"。如果觉得顶部还需要一点个人元素，后续可加小标记，但不阻塞当前设计。

【07-25 07:12】三个拍板：允许自定义分支 / 视觉标记都不加 / 先部署静态站试水

• 我问：（用 AskUserQuestion 一次性确认三个待拍板点——分支通用性、视觉标记落点、推进优先级）
• 你答：① 分支 = 允许不同项目自定义不同分支；② 视觉标记 = 都不加（纯文字）；③ 推进方向 = 先部署静态站试水（用 EdgeOne 把原型部署成 projects.sixstars.cn 实测）。
• 解释：三个决策把"需求打磨"正式推入"实施"拐点。① 允许自定义分支——比统一套用更灵活，但原型当前写死 5 分支的数据结构要改；考虑到"先试水"，决定先用当前原型部署看效果，自定义分支作为后续迭代项（不阻塞试水）。② 视觉标记都不加——和 V02.08 顶部去个人标记一致，纯文字最干净，底部落款已含个人标记署名，无需额外图形。③ 先部署试水——这是从"需求打磨"转向"实施"的关键信号；静态站走 EdgeOne Pages 海外区（已验证链路，见附录 C），iMac 不用开、免费、CDN 快。但部署有前置依赖：EdgeOne API Token（敏感凭证，在需求方手里）+ 腾讯云 DNS 加 projects.sixstars.cn 的 CNAME；且本环境 edgeone-pages 连接器当前 disconnected，需需求方在 MBA 本地终端跑（昨日 sinopec_analysis 已验证 CLI 可用）或等连接器连上。这些按"不擅作主张 + 主动追问"规矩，先理清依赖再执行，不闷头硬上。

【07-25 07:21】新增全局大原则：积分/额度消耗须先确认

• 我问：（需求方主动提出）增加一个大原则——在可能用到积分的情况下，务必反馈并获得我的确认后再进行，或通过本地设置的本地大模型试水。
• 你答：确认此为大原则，要求：① 任何可能动用积分/额度的操作，先反馈、获确认后再进行；② 或优先走本地设置的本地大模型试水，避免消耗主额度。
• 解释：这是资源消耗层面的硬约束，与 V02.02 的"不擅作主张 + 主动追问"一脉相承，是"我们怎么一起干活"规范链条的新一环。落地含义有三：a) 触发面——调用付费模型、生成图像/视频等多模态产出（系统提示已注明图像/视频各自消耗独立积分）、云端部署/调用付费 API 等，都算"可能动用积分"；b) 动作——这类操作前我先停下来，把"要做什么、预计消耗什么"讲清楚，等你拍板再动，绝不闷头默认执行；c) 替代路径——若你本地已设本地大模型（如 Ollama 等），优先用本地模型试水，把主额度留给真正需要的场景。已写入全局记忆 ~/.workbuddy/MEMORY.md（跨项目通用），本任务文档同步升 V02.10 记录。

【07-27 06:58】继续打磨：把跑偏分支预留出来，待一个一个确认

• 我问：（原始表述）"继续打磨最初的需求（iMac 改造成服务器），将跑偏的分支都预留出来，等待我一个一个继续确认。"
• 你答：确认——把对话中跑偏的方案从主线捞出来，结构化挂起为「预留项」，每条标注「待确认归类」+ 我的建议，由需求方逐个拍板（丢弃 / 留作备选 / 并入主线 / 另起话题）。
• 解释：当前已识别的跑偏分支 = alpha/beta 版本控制增强方案（此前以"运维通"身份误生成，把软件构建阶段 α/β 错当成文档版本号体系，且内容偏离 iMac 服务器主线，属理解偏差产物，从未写入主文档）。已新增「十一、跑偏分支预留清单」挂起该项，并预留"待需求方补充"槽位——若你心中还有其他跑偏分支，告诉我即可逐条补入，不擅自归类。状态保持"需求基本定稿，进入试水部署"，不阻塞试水。版本 V02.10 → V02.11（小改：新增预留清单章节）。

【07-27 07:20】首次模拟执行整个计划（非真执行）+ 产出模拟执行手册

• 我问：（原始表述）"首次模拟执行整个计划（非真的执行），并通过文字描述具体化操作每个环节的每个细节（经可能准确及傻瓜化）。"
• 你答：确认——把计划当"彩排"，全程不改动真实环境，产出独立交付物 imac-server-dryrun.md（V01.00，模拟执行手册）。手册按"阶段 0 准备+判断网络 → 第一优先级操作通道(Cloudflare Tunnel+Access+Portainer+远程桌面预案) → 第二优先级展示通道(静态试水 EdgeOne 分支C / 动态服务分支A·B挂起模拟) → 监控(Uptime Kuma) → 端口口诀 → 按需上服务 → 安全运维补课(挂起) → 验收清单"逐环节拆解，每步给"点哪里/敲什么/预期看到什么/卡住怎么办"，并统一图例（🖱️点击 ⌨️命令 👀预期 ⚠️坑 🔌前置）。
• 解释：这是计划的"操作化彩排"而非实战。关键精确点已落进手册：① EdgeOne CLI 部署必带 -a overseas（漏了默认 global 找不到海外区项目会误建第二个）；② 端口口诀 8 对外(8443)/9 管理(9001 Portainer·9002 NPM·9003 Uptime Kuma·9004 DDNS-GO)/5 应用/4 数据库(绝不对外)，对外只记 8443；③ 操作通道不依赖公网 IP；④ 静态试水当前最该落地（V02.09 已拍板"先部署静态站试水"），前置依赖 EdgeOne Token 在手 + 腾讯云 DNS 加 projects CNAME + 本环境 edgeone-pages 连接器 disconnected 需 MBA 本地终端跑 CLI；⑤ 动态服务(分支A/B)与安全运维补课挂起不阻塞。手册与主文档、概览同步交叉引用。版本 V02.11 → V02.12（小改：新增模拟执行手册交付物 + 问答记录）。

九、矛盾观察清单

本节记录在打磨过程中发现的、需求前后可能存在矛盾或设计张力之处。发现即记录，并给出供选择的建议。

观察 1：「对外提供服务」vs「自用为主」的定位张力 ✅ 已解决

• 发现时间：07-23 07:52（v0.4）
• 解决时间：07-23 08:05（v0.5）
• 需求方拍板：自用 + 预留对外扩展。核心诉求是「MBA 随时随地稳定操作 iMac」+「对外仅展示内容」，自用为主兼带展示炫耀。
• 方案落实：网络层重构为双通道设计——操作通道（第一优先级）+ 展示通道（第二优先级）。

观察 2：「随时随地操作」的具体形式 —— 远程桌面 vs Web 管理界面 ✅ 已解决

• 发现时间：07-23 08:05（v0.5）
• 解决时间：07-23 08:19（v0.6）
• 需求方拍板：形式 C——先按形式 A（Web 管理界面）做，需要时再加形式 B（远程桌面），做好扩展准备。原则：Web 能解决的优先，除非搞不定才用「在外直接访问 iMac 桌面操作鼠标」（"方便优先·保留预案"原则见第二节）。
• 方案落实：第 6 层重写为「Web 管理优先 + 远程桌面预案」。主动补盲区「管理面同生共死」（详见第 6 层），明确远程桌面是"备用钥匙"。预案推荐国内方案（向日葵/ToDesk，免费版够），不走 Cloudflare Tunnel（延迟敏感）。iMac「屏幕共享」开关作为零成本预留现在就开。
• 成本锁定：操作通道零额外成本。Web 管理免费；远程桌面预案用免费版够，真需要时 5 分钟接入。

注【v0.6 勘误】：v0.5 矛盾观察 2 中形式 A/B 的描述与第 6 层方向相反（v0.5 此处 A=远程桌面、B=Web，而第 6 层及需求方理解中 A=Web、B=远程桌面）。v0.6 已统一为 A=Web 管理、B=远程桌面、C=先 A 后 B，以需求方决策为准。

观察 3：未备案 .cn 域名 vs 展示通道方案 ✅ 已解决（V02.00 修正）

• 发现时间：07-23 08:58（v0.8）
• 解决时间：07-23 10:36（V02.00）
• 需求方拍板：需求方指引查证昨日项目 sinopec_analysis，实地确认 stocktrading.sixstars.cn 走的是腾讯云 EdgeOne Pages（海外区）。
• 方案落实（指向观察 4 / 附录 C）：未备案 .cn 域名天然不适合端口转发（国内拦截 80/443），唯一已验证出路是腾讯云 EdgeOne Pages 海外区——不要求备案、不需公网 IP、不需 iMac 常开。其完整技术链路与"EdgeOne vs iMac 本地服务器"的架构分工，已在观察 4 与附录 C 详述，此处不重复。
• ⚠️ 勘误【V02.00】：v0.8 此处推测"stocktrading 大概率走了 Cloudflare"是错误的，实际走腾讯云 EdgeOne Pages 海外区（Cloudflare 仅用于反馈表单临时隧道，不用于展示站）。全文相关表述已据实地查证纠正。

观察 4：EdgeOne Pages 云端静态托管 vs iMac 本地服务器 ✅ 已解决

• 发现时间：07-23 10:36（V02.00，查证 stocktrading 走通方式时浮现）
• 解决时间：07-23 10:48（V02.01）
• 需求方拍板：选方案 A（分工）——静态展示走 EdgeOne Pages（已验证·免费·iMac 不用开），动态服务才走 iMac 本地服务器。
• 方案落实：① iMac 服务器定位重新明确——静态上云、动态留本地，iMac 只管动态服务 + 操作通道 + 存储；② 展示通道架构图更新——静态展示走 EdgeOne（分支 C，独立于 iMac），动态服务走 iMac（分支 A/B，iMac 必须常开）；③ projects.sixstars.cn 定性为静态展示，直接复用 EdgeOne Pages 部署（见附录 B/C）；④ 展示通道架构决策状态 🟡→🟢。
• 表现：
• stocktrading.sixstars.cn 走的是 EdgeOne Pages——这是云端静态托管：HTML 文件传到腾讯云 EdgeOne，由云端 CDN 分发，iMac / MBA 完全不需要开机。
• 而 iMac 服务器方案的核心是"iMac 当服务器对外提供服务"——内容在 iMac 本地，iMac 必须常开。
• 这是两种完全不同的架构，不是同一件事。
• 这意味着（重要认知）：
• 对于 projects.sixstars.cn 这种"展示内容"：如果是静态展示（像 stocktrading 那样的 HTML 页面），直接复用 EdgeOne Pages 即可，根本不需要 iMac 当服务器——内容传到云端，iMac 不用开机，访问还更快（CDN 分发）。
• 只有当展示内容需要动态后端（数据库查询、实时交互、用户登录后个性化内容）时，才需要 iMac 当服务器 + 对外通道。
• 换句话说：iMac 当服务器的价值，在于"跑动态服务"（容器、数据库、后端逻辑），而不在于"放静态页面"——静态页面云端托管更省心。
• 选项：
• 选项 A（推荐）：区分"静态展示"和"动态服务"两类需求。静态展示（projects 页面、报告站等）走 EdgeOne Pages 云端托管（已验证、免费、不依赖 iMac）；动态服务（需要后端逻辑的）才走 iMac 本地服务器 + 对外通道。这样 iMac 只在真正需要时才承担动态服务，平时不用为静态页面常开。
• 选项 B：全部走 iMac 本地服务器——统一管理，但 iMac 必须常开，静态页面也要占 iMac 带宽，且未备案域名走端口转发有风险。
• 选项 C：全部走云端托管（EdgeOne Pages + 腾讯云函数等）——彻底不用 iMac 当服务器，但动态服务要改造适配云端，成本和复杂度上升。
• 我的建议：选 A。你的 stocktrading 已经验证了 EdgeOne Pages 这条路（静态内容云端托管，iMac 不用管）。projects.sixstars.cn 大概率也是静态展示（项目列表 + 详情页），直接复用 EdgeOne Pages 最省心。iMac 留给"真正需要本地算力 / 动态后端 / 大容量存储"的场景——这才是 iMac 当服务器的真正价值。

✅ 已拍板（V02.01）：需求方选定方案 A（分工）。静态展示走 EdgeOne Pages（已验证·免费·iMac 不用开），动态服务走 iMac 本地（必须常开）。iMac 定位 = 动态服务 + 操作通道 + 存储，不为静态页面常开。projects.sixstars.cn 定性为静态展示，直接复用 EdgeOne 部署。

后续如发现新的矛盾或张力，会在此节持续追加。

十、下一步

当前处于需求基本定稿，进入试水部署阶段，按大原则推进：

1. ~~矛盾观察 4~~ ✅ 已解决（V02.01）：需求方拍板方案 A（分工）——静态展示走 EdgeOne Pages，动态服务走 iMac。核心架构决策全部明确。
2. ~~projects 细节 3 项~~ ✅ 已拍板（V02.09）：① 第二层分支 = 允许不同项目自定义（原型后续改灵活结构）；② 视觉标记 = 都不加（纯文字）；③ 顶部去个人标记后不补元素（维持现状）
3. 待你在家做：判断有没有公网 IP（5 分钟）——只影响"动态服务"走分支 A 还是 B，不卡"静态展示"（已锁定 EdgeOne Pages）。优先级低。
4. 日常运维（断电恢复开机预案·Apple Silicon 不支持断电自启）方案已落档（十二章）·待执行；安全防护（暴露公网风险、弱口令爆破）+ 备份策略 + SSD 寿命仍待补课。
5. 随时可做：对方案任何部分提出疑问或细化想法，我按「我问→你答→解释」更新本文档并给最新版。
6. ~~暂不做~~ 🔄 已启动试水部署（V02.09 需求方选定"先部署静态站试水"）：静态站用 EdgeOne Pages 海外区部署，iMac 不用开。B 类安全运维补课仍挂起，等动态服务真要做时再补。

V02.09 后决策状态：需求基本定稿，进入试水部署。矛盾观察 4 条全部解决 ✅；projects 网页细节 3 项已拍板 ✅（允许自定义分支 / 视觉标记都不加 / 顶部不补元素）；公网 IP 实测与 B 类安全运维补课挂起不阻塞（静态展示已锁定 EdgeOne，iMac 不用开）。下一步用 EdgeOne 把原型部署成 projects.sixstars.cn 试水。

📌 模拟执行手册：把本计划拆成 10 节傻瓜化步骤（非真执行）的独立交付物见 imac-server-dryrun.md（V01.00），与主文档交叉引用；试水前建议先通读一遍，按「阶段 0 → 操作通道 → 展示通道静态试水 → 监控 → 验收」顺序走。

十一、跑偏分支预留清单

本节把对话中跑偏的方案 / 分支从主线捞出来，结构化挂起为「预留项」，等待需求方逐一确认。确认方式：每条标注「待确认归类」+ 我的建议，需求方拍板 → 丢弃 / 留作备选 / 并入主线 / 另起话题。（首项 alpha/beta 已于 V02.14 确认「保留」，作为理解偏差存档留存清单内）

跑偏项 1：alpha/beta 版本控制增强方案【运维通身份误生成 · 已确认·保留】

• 出现背景：此前以"运维通"身份生成的一份「版本控制增强方案文档」，内含 alpha / beta 构建类型、预发布通道（release channel）、构建流水线等一套机制。
• 为何判定为跑偏：这是对我方已确立的版本号命名规范（V 大写 + 主版本两位补零 + 二级 .01~.99，见 V01.00）的理解偏差——把软件工程的"构建阶段（α/β）"错当成文档版本号体系；且内容（release channel、构建流水线）与"iMac 改造成服务器"这条主线需求不是一回事。
• 处理现状：该方案从未写入主文档（v0.10 以来一直没纳入），仅停留在当时对话产物中。
• 我的建议（已采纳·保留）：保留本条，作为"理解偏差产物"的存档示例——它虽与 iMac 主线无关，但记录"身份 / 语义误解如何导致跑偏"，对后续打磨有参照价值；其"丢弃 / 另起话题"的判断仍成立，仅作为清单内的保留项留存，不并入主线、不另起话题。
• 状态：✅ 需求方拍板·保留（2026-07-27 07:40）——跑偏清单整体保留，本项作为"理解偏差存档"留存在清单内，不丢弃、不并入主线、不另起话题。

待需求方补充的跑偏项

以上为目前已识别的跑偏分支。若你心中还有其他"跑偏的分支"（某轮探索的方案、某份副产物、某个被带偏的方向），请直接告诉我，我逐条补进本清单、同样标注「待确认归类」，不擅自归类。

确认节奏：按你"一个一个继续确认"的要求，每条独立拍板，不批量跳过。

十二、电源与容量扩展预案【V02.15 新增 · 2026-07-27 10:58】

本章来自需求方提出的两个咨询：① iMac 做服务器对电源的要求；② 假设新增另一台不同规格 iMac，软硬件上如何做扩展预留。核心结论已实测核实，修正了此前"断电自启可配置"的误解。

12.1 核心事实（已核实）

• Apple Silicon iMac 断电恢复供电后不会自动开机。pmset autorestart 在 Apple Silicon（M1/M2/M3/M4）上无效/被忽略——多源实测一致（Mac mini Apple Silicon 断电插电不启、Apple 社区、CSDN 技术文）。
• 推论：iMac 服务器不能指望断电自启，电源预案必须改为"尽量不让它关机 + 关机后有人/机制开机"。

12.2 电源要求

1. UPS 必选（不是可选项）

• 目的：扛住市电闪断/跳闸的短暂停电，让 iMac 持续供电不关机。
• 选型：24" Apple Silicon iMac 待机约 10–20W、满载约 100–150W，选 600–1000VA 入门 UPS（APC Back-UPS / CyberPower）可撑 20–40 分钟。
• 关键配置：UPS 带 USB 通信，在「系统设置 → 电池/能源 → UPS」设"电量低于 X% 或剩余 Y 分钟时自动干净关机"——保护 SSD 与文件系统不被突然断电损坏（比"自启"更实际）。

1. 长停电恢复后的开机预案（真正痛点）

• 务实结论：家庭场景 = UPS 扛短停 + 长停后远程桌面/请人按电源键开机，把"开机"纳入操作通道预案。若某服务真不能容忍人工介入，再考虑把该服务迁出到支持断电自启的设备。

1. 其他电源要求：独立回路（别和空调/冰箱共插座，启动冲击）；防浪涌（老旧小区加防浪涌插排）；接触可靠（插座/线别松动）；散热（长时间高负载注意温度，降频+寿命，机身周边留通风）。

12.3 容量扩展预案（新增另一台不同规格 iMac）

• 前提认知：Apple Silicon iMac 内存/存储焊接不可升级，"增加算力/内存/存储"的唯一现实路径是横向加机器（或换更高配机型）。扩展预案 = 横向扩展（scale out）设计。

12.3.1 硬件预留

1. 网络骨干：两台都走有线千兆（iMac 自带以太网口，别用 WiFi 当服务器骨干）。若新机规格不同只有 WiFi，必须加雷雳/USB-C 网口。固定 IP：imac-01 = 10.0.0.11、imac-02 = 10.0.0.12，子网 /24。
2. 角色按规格划分（关键设计点）：

• 旧机（内存小/算力弱）→ 轻量稳态：隧道入口、静态缓存、监控 agent、反向代理
• 新机（内存大/算力强）→ 重负载：数据库、构建、模型推理、大文件存储

1. 电源：每台独立 UPS（或一台大 UPS 带两台），各自配自动干净关机。
2. 端口口诀维持（完整规划见第三节端口规划参考）：对外只记 8443、管理 900x、应用 5xxx、数据库 4xxx（绝不对外）；第二台用相同端口 + 不同 IP，靠反向代理区分。

12.3.2 软件预留

1. 入口统一（反向代理）：Nginx Proxy Manager（NPM）作统一入口，按子域名/路径把流量分发到两台对应服务。NPM 建议跑在旧机（轻量稳态）。
2. 操作通道去中心化：两台各自建 Cloudflare Tunnel + 各自 Portainer（manage-01 / manage-02）。这正好解决"管理面同生共死"盲区——每台管理面在自己机器上，一台挂了不影响另一台。
3. 故障转移：Cloudflare Tunnel 支持配置多个 origin（源），天然实现两台互备/负载——"不同规格机器互为备份"的软件层关键。
4. 服务拆分策略（按规格差异落位）：算力密集→新机；内存密集（DB/缓存）→内存大的；存储密集→盘大的（或外接阵列挂某台，NFS/SMB 共享给另一台）；无状态轻服务→任意，倾向旧机。
5. 共享存储：文件级用 NFS/SMB；对象级走 EdgeOne/COS（已是方案一部分，静态上云两台都拉，不依赖本地互访）；数据库可预留主从（主在新机、从在旧机作热备，但 Apple Silicon+图形化偏好下先预留不急做）。
6. 编排：保持每台独立 OrbStack+Portainer（去中心化）。不推荐上 Docker Swarm/k8s（对图形化偏好偏复杂），仅备注"未来 >3 台再考虑"。
7. 监控统一：两台都部署 node_exporter，纳入同一 Uptime Kuma + Prometheus/Grafana；告警要能区分"哪台挂了"，尤其 NPM 依赖两台时。
8. 可复制的加节点 SOP：命名 imac-03、IP 规划、NPM 加 upstream、Tunnel 加 origin——形成模板，未来加任意规格机器按图施工。

12.4 状态

• ✅ 本章为 V02.15 新增落档；同时修正了前文"断电自启可配置"的旧表述（§3 稳定性、第十一章需补课项、dryrun 手册第八节）。
• 电源与扩展预案不阻塞试水部署（试水仅用 EdgeOne 静态站，iMac 不用开）。

附录 A：使用 WorkBuddy 的认知与复用机制【v0.7 新增】

这是需求方提出的一个附加问题（关于使用 WorkBuddy 本身），按其要求作为附录放在文档最后。

A.1 需求方的附加问题

「昨天我做的一个任务的实现过程和各种调用打通环节，今天这个任务能够直接沿用吗？」

A.2 搜索结果 + 昨日任务具体化【v0.8 更新】

搜索 2026-07-22 对话记录无结果（两次搜索均未命中）。但 v0.8 需求方已明确告知昨日任务内容：

昨日任务：用未备案域名 sixstars.cn 设置了访问页 stocktrading.sixstars.cn（子域名 + 网页部署 + 访问配置）。

这意味着：域名环节 iMac 方案里"买域名"这步已完成。V02.00 已查证 stocktrading.sixstars.cn 走腾讯云 EdgeOne Pages（海外区）（非 Cloudflare，详见附录 C），原"需确认访问方式"已闭环。

A.3 核心认知：WorkBuddy 的"东西"存在哪、哪些跨任务

这是个需要补的认知盲区：你在 WorkBuddy 里做任务产生的东西，存在不同地方——有的跟着你走（跨所有任务），有的被关在某个项目里（换个项目就没了）。这直接决定能不能沿用。

四层存储，从"最通用"到"最局限"：

A.4 回答你的问题

"昨天那个任务的实现过程和调用打通环节能否直接沿用"——取决于它当时沉淀成了什么形态：

A.5 怎么让"能沿用"最大化（给你的建议）

如果你希望某个任务的成果以后能直接复用，最好的做法是主动沉淀：

1. 可复用的工作流 → 让我存成「技能」（用户级），以后任何任务都能一键调用。比如"从零搭 iMac 服务器"这套流程，定稿后可以存成技能。
2. 长期事实/偏好 → 写进用户级记忆，每次自动带上。
3. 连接器配置 → 自动全局共享，不用管。
4. 项目文件 → 如果要跨项目用，复制一份到新项目，或我帮你迁移。

A.6 复用判断【v0.8 更新】

昨日任务（stocktrading.sixstars.cn 配置）的复用情况：

建议：把"新建子域名访问页"这套流程存成用户级技能，以后任何新子域名（projects、blog、wiki……）都能快速复用。等 projects 配置流程定稿后我来存。

✅ 已闭环（V02.00）：stocktrading.sixstars.cn 走腾讯云 EdgeOne Pages（海外区），详见附录 C；projects 直接复用，矛盾观察 3 已解决。

这也是"方便优先·保留预案"原则在 WorkBuddy 使用层面的体现——让该复用的东西自动跟着你走，不该丢的主动沉淀下来。

附录 B：projects.sixstars.cn 三层网页设计方案【v0.8 新增】

需求方想沿用昨天配置 stocktrading.sixstars.cn 的流程，新建 projects.sixstars.cn，做三层结构的个人项目展示页。本附录是设计方案（需求打磨阶段，暂不实施）。

B.1 与昨日配置的复用关系

昨天配置 stocktrading.sixstars.cn 的流程，今天可以复用——本质就是「加子域名 DNS 记录 → 部署网页 → 配置访问」这套步骤。projects 和 stocktrading 是同一个域名 sixstars.cn 的不同子域名，DNS 配置在同一个域名管理后台，复用度很高。

但"直接调用"取决于昨天的流程有没有沉淀：

• 如果昨天只是在当时操作了（没存成技能/文档）→ 今天得重走一遍，但你会了，会快很多
• 如果沉淀成了技能 → 一键复用
• 建议：把"新建子域名访问页"这套流程存成用户级技能，以后任何新子域名都能快速复用

✅ 已确认【V02.00】：stocktrading.sixstars.cn 走的是腾讯云 EdgeOne Pages（海外区），不是 Cloudflare（之前推测有误，已纠正）。projects.sixstars.cn 可直接复用同一套部署方式——见附录 C 完整复盘。

B.2 三层结构设计

第一层：首页（项目列表 + 留言板 + 邮箱）

• 布局【V02.03】：左侧主体 = 项目列表，右侧 = 简易留言板（根据需求新增要求）；手机端自适应为上下堆叠（列表在上、留言板在下）
• 项目列表内容：罗列具体项目的列表 + 每个项目的启动时间
• 样式：简约列表，每行一个项目，显示项目名 + 启动日期
• 顶部【V02.08 改】：主标题「内容分享」+ 副标题「仅供学习交流」（去掉原个人标记——个人标记只在底部落款保留）
• 交互：点击某项目 → 进入第二层
• 分页【V02.03】：项目多了用分页（如每页 10 条），底部翻页器，不用无限滚动——减少页面过长导致的竖向滚动
• 留言板【V02.03 新增】：
• ⚠️ 留言板是动态功能（需后端存储留言数据），按 V02.01 拍板的分工原则——它不该放 iMac（太轻量，不值得为它常开 iMac），而应走云端轻量后端（云函数 + 云数据库），符合"静态上云、动态留本地"的分工
• 方案待需求方拍板（见 B.4），候选：Twikoo（腾讯云函数，推荐）/ Giscus（GitHub Discussions）/ 其他
• 留言板只放首页右侧，不侵入三层结构主体
• 个人邮箱【V02.06 根据需求新增】：
• 邮箱地址：sixstars@qq.com
• 位置：首页顶部主副标题下方（与留言板形成两种联系途径——留言板是"留痕"，邮箱是"私信"）
• ⚠️ 防垃圾邮件：邮箱暴露在公网页会被爬虫抓取。采用 JS 动态拼接防爬——HTML 源码不写完整邮箱、JS 运行时拼接并动态生成 mailto:，访客正常显示可点击、爬虫抓不到。完整方案、代码与备选（邮箱图片）均见 B.3 邮箱防垃圾邮件方案。

第二层：项目管理分支（项目详情页）

点击某项目后，按项目管理理论展开分支列表。简约版 5 个分支：

设计理由：PMBOK 十大知识领域对个人项目太重，精简为 5 个最常用的。你提到的"需求、工具"已包含，另外补"进度、成果、备注"形成完整闭环。可按需增减。

第三层：具体内容

• 点击某分支 → 进入该分支下的具体内容页
• 内容形式：文本、图片、链接、代码片段等
• 面包屑导航：首页 > 项目名 > 分支名，方便回上层
• 分页【V02.03】：单条内容过长时分页（如每页约一屏阅读量），底部翻页器——减少竖向滚动
• 简约排版，以可读性为主

B.3 设计风格

核心要求：最简单、经典框架、简约为主。

个人标记「大欣，欣欣向荣的欣」（规范写法，见全局记忆 ~/.workbuddy/MEMORY.md）：

• "欣"字本义：喜悦、繁荣；"欣欣向荣"寓意蓬勃发展
• ⚠️ 写法硬约束：全称固定为「大欣，欣欣向荣的欣」，不要多字、少字，也不要随意改写（如不要写成"需求方，欣欣向荣"、"需求方(欣欣向荣的欣)"等）——需求方 2026-07-23 明确要求
• 位置【V02.08 改】：个人标记从页面顶部移除（顶部改为主副标题），仅在底部落款保留（sixstars.cn ☆ 大欣，欣欣向荣的欣 ☆ 定稿时间）。顶部不再放个人标记
• Logo 方向（待定）：一个简约的「欣」字 + 一抹生长的绿（呼应"向荣"），或一片嫩叶图形——作为后续视觉标记可选项，待需求方确认偏好方向
• 配色：主色清新绿（如 #4A7C59），辅以米白底（#FAFAF7），文字深灰（#333）
• 字体【V02.03 需求方要求"体现计算机专业"】：
• 标题 / 代码片段 / 强调元素：JetBrains Mono（等宽字体 monospace，JetBrains 出品，程序员主流字体，免费可商用）——等宽字体是计算机专业的视觉符号（终端、代码编辑器都用），辨识度高、"代码感"强
• 中文正文：思源黑体（Source Han Sans / Noto Sans CJK SC）（开源、可读性好、现代干净）——保证大段中文阅读舒适
• 搭配理由：等宽 + 黑体，既有计算机专业气质又不牺牲中文可读性；标题用等宽凸显"技术人"身份，正文用黑体保证阅读体验
• 加载方式：字体文件自托管（和网页一起部署到 EdgeOne Pages），不依赖 Google Fonts（国内访问不稳）；也可用 jsDelivr 等 CDN 引入
• 整体气质：清爽、有生机、不花哨

自适应与分页【V02.03 根据需求新增要求】：

• 响应式自适应：PC 端 + 手机端都要适配，用 CSS media queries + flexbox/grid 布局；手机端布局自动堆叠（如首页左列表+右留言板 → 手机端变上下）
• 兼容主流浏览器：Chrome / Safari / Firefox / Edge 最新版
• 减少滚动条【核心要求】：① 尽量避免横向滚动（响应式自适应宽度）；② 竖向内容多了用分页替代无限滚动（首页项目列表分页 + 第三层长内容分页）；③ 单页内容控制在"尽量一屏可览核心信息"，超出部分翻页
• viewport：HTML head 加 <meta name="viewport" content="width=device-width, initial-scale=1">，确保手机端正确缩放

网页标题【V02.04 根据需求新增·V02.08 更新】：

• 浏览器标签页 <title> = 内容分享（仅供学习交流）
• 页面顶部【V02.08 改】：主标题「内容分享」+ 副标题「仅供学习交流」——与标签页标题呼应（同一套文案），站点定性一致
• 个人标记不再放顶部（V02.08 移除），仅在底部落款保留——标签页 + 顶部主副标题 = 站点定性（内容分享·学习交流），底部落款 = 个人署名（域名 + 个人标记 + 时间），各司其职

遵纪守法提示【V02.04 根据需求新增】：

• 页面底部（落款上方）加一行小字提示，如：「本站内容仅供学习交流，请遵守中华人民共和国相关法律法规。留言内容仅代表访客个人观点，与本站无关。」
• 有留言板（用户生成内容）时这条尤其必要——国内合规要求

• 问题：邮箱明文写在网页 HTML 里，会被自动爬虫批量抓取（爬虫扫遍互联网收集邮箱用于发垃圾邮件），后果是垃圾邮件泛滥。
• 方案：JS 动态拼接（推荐，默认实现）——HTML 源码里不出现完整邮箱字符串，而是这样写：

邮箱防垃圾邮件方案【V02.06 根据需求新增】： ``html <!-- 源码里只有占位，爬虫读到的是空的 --> <span id="contact-email"></span> <script> // JS 运行时才拼接出真实邮箱，爬虫不执行 JS 所以抓不到 document.getElementById('contact-email').innerHTML = '<a href="ma' + 'ilto:sixstars' + '@' + 'qq.com">sixstars' + '@' + 'qq.com</a>'; </script> ``

• 访客视角：打开网页看到正常可点击的邮箱，点击直接打开邮件客户端发信——体验零损失
• 爬虫视角：读 HTML 源码只看到空的 <span> 和被拆散的字符串，拼不出完整邮箱
• 进阶：可加 ROT13 编码 / Base64 编码再 JS 解码，进一步增加爬虫破解难度
• 备选：邮箱图片（若 JS 方案仍不够）——把邮箱用图片显示，爬虫读不出图片里的字。缺点：访客不能点击直接发邮件、不能复制，需手动输入。优先用 JS 方案，图片方案作为兜底。
• 不要做的事：❌ 直接在 HTML 里写 sixstars@qq.com（裸邮箱必被抓）；❌ 只用 CSS 隐藏（爬虫仍读得到源码）

实时数码时钟【V02.06 根据需求新增】：

• 位置：所有页面右上角（固定区域，随页面通用，可做成 header 组件的一部分）
• 显示内容：日期 + 时间，格式如 2026-07-23 11:46:55（年-月-日 时:分:秒，24 小时制）
• 字体：JetBrains Mono（等宽字体，与整体字体方案一致，数码管质感、"代码感"呼应计算机专业定位）
• 实现：前端 JavaScript，setInterval 每秒刷新一次，取浏览器当前时间
• ✅ "服务器相关"含义已确认【V02.07 需求方拍板】：原始表述"服务器相关的显示日期和时间"，确认为理解 A——显示当前时刻的实时时钟（北京时间），"服务器相关"指风格/气质上像服务器机房数码钟。纯前端 JS 实现，无后端依赖，和静态站定位不冲突。（理解 B=显示 iMac 运行状态，不采用，因需 iMac 常开+状态上报，与静态站定位冲突。）

技术实现方向（待定稿后选）：

• 最简方案：纯静态 HTML/CSS，三个层级用多个 HTML 文件 + 超链接
• 进阶方案：用轻量框架（如 Hugo/Astro）生成静态站，方便后续加项目
• 部署【V02.00 已明确】：复用 stocktrading 已验证的腾讯云 EdgeOne Pages（海外区）——未备案可用、免费、CDN 分发、不需 iMac 常开。projects.sixstars.cn 在 EdgeOne 新建一个项目（或复用 stocktrading 项目加子路径），腾讯云 DNS 加一条 CNAME 即可。详见附录 C。

B.4 待你确认

1. ~~第二层的 5 个分支是否够用？要增减哪些？~~ ✅ 已拍板（V02.09）：改为"允许不同项目自定义不同分支"——各项目可定义自己的分支结构。原型当前写死 5 分支，试水部署后改灵活数据结构（项目自带分支定义）。
2. ~~"欣欣向荣"的视觉标记~~ ✅ 已拍板（V02.09）：选"都不加"——顶部不加绿叶符号、底部落款不加小标记，维持纯文字现状。
3. ~~stocktrading.sixstars.cn 现在走什么方式访问？~~ ✅ 已确认走 EdgeOne Pages 海外区（V02.00），projects 可直接复用，见附录 C。
4. 留言板方案待拍板【V02.03 新增】：留言板是动态功能，按分工走云端轻量后端（不放 iMac）。候选方案：

• Twikoo（推荐）：轻量评论/留言系统，部署到腾讯云 CloudBase（云函数 + 数据库）。优点——国内访问好、未备案域名走海外区函数可用、界面干净、免费额度够个人用、需求方有腾讯云基础生态契合。缺点——需部署一次云函数 + 数据库（约 20 分钟，我可带做）。
• Giscus：基于 GitHub Discussions。优点——零成本零运维、未备案可用。缺点——访客需 GitHub 账号才能留言、国内访问 GitHub 偶不稳。适合"技术圈朋友"为主的场景。
• 先不做留言板：先把三层结构 + 自适应 + 分页做出来，留言板后续需要时再加（首页右侧先留位）。
• 场景明确【V02.04 需求方补充】：留言板用途 = "访客初次留痕"（轻量，非深度讨论）。由此 Giscus 基本排除——它要求访客有 GitHub 账号，普通访客（朋友、同事等非程序员）没有，留不了言。
• ✅ 已确认【V02.05 需求方拍板】：选 Twikoo——访客直接输入就能留痕，不需要任何账号；和 EdgeOne 同属腾讯生态、国内访问稳、未备案可用、免费够用。这步在静态页做好之后再接，不阻塞主体。

1. ~~数码时钟"服务器相关"含义待确认~~ ✅ 已确认【V02.07 需求方拍板】：选理解 A——就是右上角实时数码时钟，显示当前日期+时间（北京时间），"服务器相关"指风格气质（像服务器机房数码钟），纯前端 JS 无后端依赖。理解 B（iMac 运行状态）不采用，与静态站定位冲突。

• 原歧义记录【V02.06】：原始表述"服务器相关的显示日期和时间"，两种可能理解——理解 A（实时时钟，推荐）/ 理解 B（iMac 运行状态，需 iMac 常开+状态上报+前端轮询，与静态站定位冲突）。需求方确认 A。

附录 C：昨日 stocktrading 走通方式复盘（已验证链路）【V02.00 新增】

需求方要求实地查证昨日项目 sinopec_analysis 里 stocktrading 走通的方式，补充到本文档。本附录是基于昨日项目实际文件 + 工作日志的查证复盘，已脱敏（不含 token、邮箱授权码等敏感凭证）。

C.1 核心结论

stocktrading.sixstars.cn 走的是腾讯云 EdgeOne Pages（海外区），不是 Cloudflare。

⚠️ 勘误：之前 v0.8 推测"大概率走了 Cloudflare"是错误的。Cloudflare 在昨日项目中仅用于反馈表单的临时公网通道（quick tunnel，trycloudflare.com 临时地址，会变），不用于展示站。展示站走的是腾讯云 EdgeOne Pages。

C.2 完整技术链路

外部用户
  │
  │  访问 https://stocktrading.sixstars.cn
  ▼
腾讯云 DNS（sixstars.cn 的解析在这里）
  │
  │  CNAME 记录：stocktrading → EdgeOne 海外节点目标值
  ▼
腾讯云 EdgeOne Pages（海外区项目 stocktrading）
  │
  │  CDN 分发 + 自动 HTTPS
  ▼
返回静态 HTML 内容（存放在 EdgeOne 云端）

关键点：内容存在腾讯云 EdgeOne 云端节点上，iMac / MBA 完全不需要开机。这和"iMac 当服务器"（内容在本地）是两种架构。

C.3 关键配置要素

C.4 部署方式

两种方式都已跑通：

1. 控制台手动上传（早期）：

• 在 EdgeOne Pages 控制台「直接上传」建项目，拖文件上传。
• 适合首次建站。

1. EdgeOne CLI 自动部署（后期，已自动化）：

• 脚本：deploy_reports.sh（在昨日项目 sinopec_analysis 里）
• 原理：从 config.py 读取 API Token 和项目名，调用 edgeone pages deploy
• 关键命令：edgeone pages deploy <目录> -n stocktrading -t <token> -e production -a overseas
• 关键坑：-a overseas 不能漏！默认 global 区域找不到海外区项目，会误判为"项目不存在"去新建第二个项目。-a overseas 指定海外区，才能正确指向已存在的 stocktrading 项目。
• 已接入每日 16:00 自动化，每天自动同步最新报告到该域名。

C.5 已实现的访问保护（昨日做的，可复用）

这些保护对未来 projects.sixstars.cn 同样适用，可一并复用。

C.6 与 iMac 方案的关系（重要认知）

结论：projects.sixstars.cn 如果是静态展示（项目列表 + 详情页），直接复用 EdgeOne Pages 最省心——不用 iMac 常开、免费、访问还快。iMac 留给真正需要本地算力的动态服务。这就是矛盾观察 4 的核心。

C.7 projects.sixstars.cn 复用指引

复用 stocktrading 的部署方式，给 projects 建站：

1. EdgeOne Pages 新建项目：在 EdgeOne 控制台新建一个海外区项目（如 projects），或复用 stocktrading 项目加子路径。
2. 准备静态文件：按附录 B 的三层结构，生成 HTML 文件（首页 + 项目详情页 + 分支内容页）。
3. 上传部署：控制台手动上传，或写个类似 deploy_reports.sh 的脚本用 CLI 部署。
4. 腾讯云 DNS 加 CNAME：projects → EdgeOne 给的目标值。
5. 访问保护：复用 stocktrading 的 noindex + 只读 JS + 口令闸门。

建议：等 projects 三层结构定稿后，把"新建子域名访问页 + EdgeOne 部署"这套流程存成用户级技能，以后任何新子域名（projects、blog、wiki……）都能快速复用。

C.8 查证来源

• 昨日项目路径：/Users/sixstars/WorkBuddy/2026-07-22-08-16-52/sinopec_analysis/
• 关键文件：
• deploy_reports.sh（部署脚本，确认走 EdgeOne CLI + -a overseas）
• .bin/cloudflared（Cloudflare 二进制，但仅用于反馈表单临时隧道，非展示站）
• .workbuddy/memory/2026-07-22.md（昨日工作日志，完整记录从尝试到落地的全过程）
• 查证时间：2026-07-23 10:36
• 脱敏说明：本附录不含 API Token、邮箱授权码等敏感凭证（这些在 config.py 里，未写入本文档）

sixstars.cn ☆ 大欣，欣欣向荣的欣 ☆ 2026.07.27-11:21:30