用 AI 写弱电方案、报价单、拓扑图：实测提效流程 周五晚上九点，客户群里弹来一句话：周一早上开会，要一份 32 路监控加门禁、再加综合布线的完整方案，含报价和拓扑图。搁以前，这就是一个周末：方案三小时，报价单两小时，拓扑图一个半小时，中间还得翻一遍设备手册核对型号。现在我用 AI 跑同一套活，方案初稿四十分钟，报价单二十分钟，拓扑图半小时——剩下的时间全部花在核对上。这篇文章就把这套流程原原本本写下来：怎么喂料、提示词怎么写、哪些地方 AI 一定会写错、以及最后那道人工关怎么把。先说一句底线：AI 在这里是起草员，不是工程师。签字栏里落的是你的名字，出问题客户找的也是你。这套流程省的是打字和排版的时间，省不掉现场勘察和最后核对。一、先说结论：AI 能干什么，不能干什么这一个月我拿真实项目跑了下来，AI 靠谱的三件事：搭框架、写套话：方案里的项目背景、需求分析、系统概述、售后条款，AI 写得比人快，也比人全。做表格、算汇总：报价单的设备清单、数量乘单价、合计、税额，AI 一次成表，改起来也方便。出拓扑草图：给清点位和组网关系，AI 能先画一版逻辑图，你再拿到 draw.io 里精修。三件千万别交给 AI 的事：定型号、定数量：它会一本正经地编一个不存在的型号，或者把 16 路 NVR 写成 32 路。定价格：它不知道你这周的拿货价，也不知道辅材涨了多少。定现场做法：桥架怎么走、机柜放哪、电源从哪取，这些只能来自你去现场看过。记住这个分工，后面所有步骤都不会跑偏。二、写方案：先喂料，再让 AI 动笔AI 写方案最常见的翻车，是上来就丢一句"帮我写一份监控方案"。没有现场信息，它只能写通用模板，客户一眼就能看出来是套话。正确顺序是：先勘察，再喂料，最后才动笔。第一步，现场勘察，记一张表。 去现场带一张纸，记下这几样：点位数量和位置（比如大门 2 路、仓库 4 路、走廊 6 路）、每个点位到机房的大致距离、机房位置和有没有现成机柜、电源取电点、客户有没有指定品牌、预算区间。这张表就是后面所有内容的地基。第二步，把料一次性喂给 AI。 我用的提示词骨架是这样的：项目背景：XX 厂区，建筑面积约 3000 平，共两层，需要新建监控、门禁、综合布线三个子系统。 点位清单：室外枪机 8 路、室内半球 16 路、仓库 4 路、门禁 4 套、信息点 40 个。 机房：二楼弱电井，有一台 12U 机柜，电源已到位。 要求：输出一份弱电工程方案，结构为项目概述、需求分析、系统设计、设备清单、施工组织、售后服务；设备选型按海康/大华同档主流型号给建议，注明"以实际拿货型号为准"。关键点：点位、距离、约束条件全部写进提示词，AI 才能写出贴合现场的东西；凡是拿不准的，让它写"建议"和"待确认"，别让它替你拍板。第三步，初稿出来后，必改三处。 第一是型号：逐个核对，AI 编造的型号直接删掉换成你实际用的；第二是数量：点位数量对照勘察表一个一个数；第三是标准号和规范引用：它爱写"符合国家相关规范"这种空话，改成具体的《安全防范工程技术标准》GB 50348 之类你真正执行的条文。改完这三处，一份能交的方案就出来了。三、报价单：表格让 AI 生成，价格必须自己填报价单我分两步走：先让 AI 按设备清单生成表格结构，再自己填价格、算合计。提示词可以这样给：根据以下设备清单生成报价单表格，列为：序号、设备名称、品牌型号、单位、数量、单价、合计、备注。 清单：海康 4MP 枪机 8 台、半球 16 台、32 路 NVR 1 台、4TB 监控硬盘 2 块、门禁一体机 4 套、六类网线 3 箱、12U 机柜 1 台…… 单价栏留空，合计栏留公式位，最后加一行"设备小计"，再加"辅材及施工费"和"税费"两行，备注栏注明线材按实测长度结算。AI 生成表格很快，但有三个坑我每次都踩过，写下来提醒自己：税率别让它定：它可能默认给你按 13% 算，也可能按 6% 算，税率按你公司实际开票情况填。辅材和人工最容易漏：水晶头、电源线、PVC 管、桥架、人工费，这些 AI 经常只字不提，清单里没有就手动补上，漏一项就是自己贴钱。数量乘单价要复算：表格合计让它算完，你再拿计算器抽查几行，尤其是数量大的那几行，错一行就是几百块。报价单发给客户之前，我的习惯是打印出来逐行念一遍。屏幕上看表格容易跳行，念出来才能发现多一个零、少一个零。四、拓扑图：AI 画草图，draw.io 精修拓扑图是三件活里 AI 最弱的一环，也是最容易露馅的一环。它能画出"像那么回事"的图，但端口号、IP 段、线缆标注经常张冠李戴。所以我的流程是：AI 只出草图，定稿一定在 draw.io 里手工改。做法分两步：先让 AI 出逻辑草图。 把组网关系用文字讲清楚："核心交换机下挂两台接入交换机，分别接 16 路摄像头和门禁控制器；NVR 和存储接核心交换机；外网经路由器接光猫；管理电脑接核心交换机。"让它用 Mermaid 画一版流程图，或者直接出一版示意图，目的是确认结构对不对——层级有没有画反、设备有没有漏。再到 draw.io 里精修定稿。 草图确认结构没问题后，我在 draw.io 里重画一版：设备图标用标准形状，标清每个端口的连接关系、VLAN 划分、IP 地址段、关键链路的线缆类型。AI 草图里写错的 IP、写错的端口号，在这一步全部改掉。这一步没有捷径，拓扑图错一个数字，施工队就可能接错一根线。这张图就是这套流程本身：现场勘察、喂料起草、报价核对、拓扑精修、交付归档，五步走完，一份方案才算真正做完。五、实测时间账：省在哪，省了多少拿最近一个 32 路监控加 4 套门禁的项目实测了一遍，时间对比是这样的：环节以前（纯手写）现在（AI 起草 + 人工核对）方案正文约 3 小时约 40 分钟起草 + 30 分钟核对报价单约 2 小时约 20 分钟制表 + 20 分钟核价拓扑图约 1.5 小时约 30 分钟草图 + 30 分钟精修合计约 6.5 小时约 2.5 小时省下来的四个小时，我全部花在了核对和现场复核上。算下来总工时省了六成，但方案出错的概率反而降了——因为以前写到后半夜，型号和数量全凭记忆硬扛，现在有固定流程逐项核对。还有一点要说实话：第一次用这套流程并不会快。提示词要调两三遍，AI 的输出习惯要摸一轮，我的第一份 AI 方案反而比手写多花了半小时。从第三份开始，速度才真正提起来。工具的红利从来不在第一次，在第三次以后。六、避坑清单：这六条我都踩过别把客户原始资料整段贴给 AI：客户给的平面图、点位表里可能有门牌号、联系方式，喂之前脱敏，只留 AI 需要的点位和尺寸。别让 AI 编标准号：它写出来的标准号有一半是对不上的，规范引用只写你确认过的那几条。价格只认自己的渠道价：AI 给的"市场价"可能是半年前的数据，报价以你当周问到的拿货价为准。拓扑图定稿前打印出来看一遍：屏幕上看着对的图，打印出来才发现线压字、字叠字。方案发出去之前，通读一遍全文：AI 的行文有个毛病，前后可能自相矛盾，前面写"采用 POE 供电"，后面又写"每路单独布电源线"，这种地方只有通读能抓出来。留一份提示词模板：把调好的提示词存下来，下个项目改几个数字就能用，这是这套流程里最值钱的东西。写在最后AI 没有让我少去现场，也没有让我少核对一个数字。它真正改变的，是我坐在电脑前那几个小时：从"一个字一个字敲"变成了"审稿、改错、拍板"。对我们这种一个人要跑现场、写方案、做报价、画拓扑的小团队来说，这四个小时省下来，能多跑一个现场，或者早点回家。工具会换，流程不会。这套流程的核心就一句话：现场你定，AI 起草，最后那道关永远是你自己。相关旧文一个门禁项目的布线到调试踩坑手记：门禁接线和调试的现场手记，本文方案里的门禁部分就是按那次的经验写的。弱电工程实战：可视对讲 + 门禁 + 网络布线联调：多系统联调的顺序和排障，方案里"施工组织"那一节的底子。群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战：监控存储和回放那部分，写方案时常要引用的实测经验。Muse / Hark 用了一个月：真提效还是玩具：本文用到的 AI 工具，一个月使用复盘。

Serv00 免费主机放号了：3GB 空间 + 完整 SSH，不要钱不绑卡 Serv00 免费主机放号了：3GB 空间 + 完整 SSH，不要钱不绑卡前言：这家免费主机又开放名额了免费主机圈子里，Serv00 是个异类：波兰运营商、FreeBSD 系统、不要钱、不绑卡、邮箱注册，还给完整 SSH 登录权限——这意味着它不只是放静态页的"网页空间"，而是能常年挂着跑你自己的程序。唯一的门槛是名额。它的服务器是一台一台开的，当前服务器满员时注册通道会关，只能等新服开放或者等有人账号被回收。现在注册通道又开了，看到这篇就赶紧申，名额说没就没。干什么用Serv00 免费版是实打实的完整主机，不是试用装：项目免费版规格磁盘空间3GB SSD月流量不限网站数100 个MySQL 数据库10 个PostgreSQL 数据库3 个MongoDB 数据库3 个内存512MB系统进程15 个开放端口3 个 TCP/UDP备份保留 7 天SSH有，完整权限域名免费子域名 login.serv00.net，也可绑自己的域名SSL免费证书价格永久免费，无广告更关键的是它给的是一台能折腾的机器：SSH 登录、cron 定时任务、多语言支持（PHP 5.6 到 8.5、Node.js、Python 都能跑）、Git/SVN/HG 仓库、远程数据库访问。拿它可以做这些事：放个人博客或静态站：WordPress、Typecho 这类 PHP 程序都能装；放演示和小工具：做个在线小工具、API 演示、项目展示页；跑定时脚本：cron 可以定时跑备份、签到、数据同步这类轻量任务；当监控和测试节点：配合家里的 NAS 或 VPS 做异地对照测试；练手：想练 Linux/服务器管理又不想先掏钱，从这里入门正合适。不适合干什么也要说清楚：服务器在欧盟，国内直连速度一般，不适合做面向国内访客的生产站；512MB 内存 + 15 进程也跑不了重负载。把它当成一台免费的折腾机，最合适。注册步骤注册地址：https://www.serv00.com/register-account/（也可以从官网首页点 Register account 进去）。填邮箱、用户名、密码：不要信用卡、不要实名，邮箱注册即可。用户名想好再填，注册后改不了；完成页面上的人机验证：按页面提示作答即可；提交后等人工审核：申请是人工审核的，官方说法是几小时到 72 小时。论坛上有人等了一周才有回信，耐心等，别重复提交——重复提交反而可能被当成滥用；收到开通邮件：邮件里会给面板地址（形如 panelXX.serv00.com）、SSH 地址和初始信息；第一件事登面板改密码：然后看一眼自己的资源限额页，数字以账号里显示的为准，不同批次的服务器规格略有浮动；开站点、建数据库：面板里添加网站、选程序类型（PHP、Node.js、Python），再用 SSH 连上去部署。避坑指南免费的东西规矩多，这几条先记牢：每 90 天至少登录一次：面板或 SSH 登录都算，长期不登账号会被回收。建议在日历里设个季度提醒，或者干脆让上面跑的定时脚本本身保持活跃并定期登一次；用途红线看 TOS：代理/VPN、挖矿、高负载滥用这类在免费主机上是通用禁区，别拿它当节点使，封号没商量；FreeBSD 不是 Linux：部分 Linux 命令和软件包行为不一样，装软件用 pkg 而不是 apt，照着官方文档 docs.serv00.com 来最稳；支持只有论坛：免费版没有客服工单，遇到问题去 forum.serv00.com 找答案或发帖；别薅羊毛式批量注册：人工审核本来就严，批量注册基本过不了，还可能连累邮箱被拉黑；名额和规格以官网为准：服务器满员通道就会关，规格也可能随批次调整，注册前以官网和面板实时显示为准。错过这次怎么办：蹲放号的小工具Serv00 的名额说没就没，这次赶上了是运气，下次什么时候开没人说得准。为了不错过下次放号，我写了个开源小工具：serv00-open-register。它干的事很简单：定时去 Serv00 官网取当前账户数和最大账户数，两个数一比较就能精确判断注册有没有开放——比盯首页按钮靠谱。一旦检测到开放，就通过 Bark 往你手机上推一条通知，点一下通知直接跳到注册页，抢名额就快人一步。用法也不用自己的服务器：把仓库 Fork 到自己的 GitHub 账号；在仓库的 Settings → Secrets and variables → Actions 里配两个密钥：BARK_KEY（Bark App 里拿到的 Key）和 BARK_SERVER_URL（用官方的填 https://api.day.app，自建 Bark 服务器就填自己的地址）；GitHub Actions 会按设定时间自动跑检测，想立刻测试也可以在 Actions 页手动触发一次。整个项目 MIT 开源，检测逻辑就在 checker.py 里，感兴趣的可以自己改检测频率和通知方式。不用了怎么办不想用了也不用特意注销，账号放着就行——但记得 90 天登一次保号，不然会被回收。真想彻底注销，可以去论坛联系管理员处理。反正不要钱，也没有自动续费这回事，不用担心扣费。写在最后免费主机年年有，但给完整 SSH、不限流量、能跑数据库和定时脚本、还不要信用卡的，数来数去就这么几家。Serv00 的名额是出了名的难抢，这次通道开了，值得第一时间申一个放着——哪怕现在没想好放什么，先拿下来保住号，再慢慢想怎么用。相关链接官网：https://www.serv00.com/注册页：https://www.serv00.com/register-account/官方文档：https://docs.serv00.com/官方论坛：https://forum.serv00.com/蹲放号小工具（本站开源）：serv00-open-register —— 定时检测注册是否开放，开放后 Bark 推送提醒相关旧文群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战 —— 家里服务跑起来之后，监控也得跟上Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清 —— 免费主机也能挂进监控里一起看状态

VPS 保活与避坑：甲骨文换 IP、丢实例怎么办 甲骨文免费 VPS 大概是白嫖圈里最香、也最让人提心吊胆的一台机器：4 核 24G 的 ARM 实例不要钱，代价是随时可能被回收、公网 IP 说换就换。我的那台跑了快两年，经历过一次换 IP、一次差点丢实例，踩过的坑都攒在这篇里。这篇接续站内旧文《甲骨文netboot重装系统遇见问题解决》，只讲保活和避坑，不讲怎么注册抢实例。先搞清楚：实例是怎么丢的甲骨文免费层有两个让人丢实例的机制，很多人是稀里糊涂中招的。第一是闲置回收。 免费实例如果连续 7 天 CPU 利用率低于 20%、网络出入流量低于 20%，甲骨文有权回收。注意是“有权”，不是“一定”，但 ARM 库存紧张的时候，回收动作会明显变勤。很多人把实例当纯反代/跳板挂着，CPU 常年 1%~2%，这就是最危险的一类。第二是区域库存与配额。 免费 ARM 实例在某些区域（比如东京、新加坡）常年缺货，实例一旦被删、被回收，同一区域很可能再也抢不到。换句话说，丢实例的代价不是“重开一台”，而是“这个区域可能再也没有了”。第三是账单与合规。 免费层绑定的信用卡过期、扣款失败，或者账号被判定异常，实例会直接停掉。信用卡有效期不到三个月的，尽早更新。所以保活的核心就一句话：让实例看起来一直在干活，同时保证它丢了也能快速重建。保活第一步：别让 CPU 闲着最简单的保活办法，是让实例定期有一点真实负载。我的做法是每天跑两次轻量任务：用 cron 跑一个系统自检脚本：更新 apt 缓存、轮转日志、跑一遍备份检查，单次 CPU 能冲到 30%~50%，持续两三分钟；实例上常驻一个真实服务：我挂的是 Lucky 反代和一个小型监控面板，本身就有进出流量。# /etc/cron.d/keepalive 每天 8:00 / 20:00 跑一次自检 0 8,20 * * * root /usr/local/bin/daily-check.sh >> /var/log/daily-check.log 2>&1#!/bin/bash # /usr/local/bin/daily-check.sh apt update && apt list --upgradable systemctl is-active lucky || systemctl restart lucky df -h / && free -h关键点是别用纯空转脚本刷 CPU。甲骨文回收规则看的是 CPU 利用率和网络流量，空转脚本刷出来的 20% 利用率和真实负载在指标上没区别，但一旦被判定为滥用，账号风险更大。用真实任务（更新、备份、日志轮转）去产生负载，既合规又有用。换 IP：甲骨文换 IP 的正确流程甲骨文实例的公网 IP 是可以换的，免费层每月前 100 小时内更换不收费（实测小额操作基本不产生费用，但以账单为准）。换 IP 的场景有两个：IP 被墙、IP 段被拉黑。操作流程：控制台 → 实例详情 → 附加的 VNIC → 临时公共 IP → 编辑 → 选择“不分配公共 IP”并保存，等一分钟；再编辑一次 → 选择“临时公共 IP” → 保存，系统会分配一个新 IP；立即 SSH 登录确认新 IP 能通，再改下游配置。换完 IP 要同步改的地方，我列个清单，漏一个就断一处：域名解析：A 记录改成新 IP，TTL 提前一天改成 300 秒，换完再改回去；Lucky / FRP 的反代目标：如果你的群晖、NAS 服务是经这台 VPS 反代出去的，检查反代规则里的上游地址；监控告警：Uptime Kuma 里监控项的地址要改，否则告警会一直误报；白名单与防火墙：家里 NAS、路由器上如果按 IP 放行了这台 VPS，记得同步更新；SSL 证书：证书跟域名走，一般不用动，但如果用了 IP 直连的证书就要重新签。我自己的教训：有次换完 IP 只改了域名解析，忘了 Lucky 里有一条规则写的是旧 IP 直连，结果图床反代断了半天才发现。从那以后换 IP 必按清单逐项打勾。丢实例了怎么办：先抢，再重建如果实例真的被回收了，别慌，按这个顺序处理：1. 先确认是不是能抢回来。 控制台 → 创建实例 → 选原来的区域和形状（VM.Standard.A1.Flex），反复刷库存。ARM 免费实例的库存是动态释放的，凌晨和工作日上午相对容易刷到。刷到后立刻创建，别纠结配置，先占住再说。2. 引导卷和数据盘还在吗？ 实例被回收时，引导卷一般也会被删，但如果你之前做了引导卷备份（控制台 → 块存储 → 引导卷备份），可以从备份恢复一个新实例。我的做法是每周自动备份一次引导卷，保留最近两份。3. 重建后按清单恢复。 按“换 IP 清单”重新走一遍：DNS、反代、监控、防火墙、证书。我的 Lucky 配置、Docker compose 文件都在群晖上另存了一份，重建一台纯净实例后，传配置、起服务，半小时能恢复。4. 如果这个区域彻底抢不到。 换区域（比如从东京换到首尔或孟买），或者接受现实：把核心服务迁回家里群晖，VPS 只留一个轻量反代。免费的东西，永远要有 Plan B。监控与备份：丢之前就要配好保活不是玄学，是监控 + 备份两件套：监控：Uptime Kuma 监控 VPS 的 SSH 端口和几个关键服务，告警推到 Bark 或邮件。实例一停，5 分钟内就能知道，而不是等用户反馈才发现。部署方法见站内旧文《Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清》。备份：引导卷每周备份；关键配置文件（Lucky 配置、nginx 配置、Docker compose）同步一份到群晖或 NAS 上。备份方案的思路见《群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好》。留一台备用：条件允许的话，在另一个区域再养一台免费实例做冷备，平时只跑监控，主机一丢，改 DNS 就能顶上去。避坑清单（照着打勾）信用卡有效期保持在三个月以上，绑卡邮箱能收到账单提醒；实例上常驻真实服务，别让 CPU 和流量长期归零；每周备份引导卷，配置文件在 NAS 上另存一份；换 IP 前把 DNS 的 TTL 改成 300 秒；换 IP 后按清单逐项改 DNS、反代、监控、防火墙，别凭记忆；别把所有服务都押在一台免费实例上，核心服务要有回群晖的退路；免费实例是“随时可能收回”的资源，别在上面放不可替代的数据。写在最后甲骨文免费 VPS 的正确用法，是把它当成一台随时可能消失的机器来用：服务能重建、配置有备份、IP 换了有清单、丢了有备用。做到这几点，换 IP 只是一次十分钟的操作，丢实例也只是一次半小时的重建。最怕的是平时什么都不准备，出事那天才发现配置只存在那台机器里。相关旧文甲骨文netboot重装系统遇见问题解决Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好

兰空图床进阶配置：多存储策略与防盗链 兰空图床进阶配置：多存储策略与防盗链图床搭起来只是第一步。用上一段时间，真正让人头疼的是两件事：图片越存越多，本地磁盘先扛不住；链接被人到处盗用，流量白白烧掉。本文是兰空图床基础篇的进阶续篇，讲多存储策略怎么配、防盗链怎么做，都是在自家图床上实测过的配置。一、多存储策略解决什么问题兰空图床（Lsky Pro）默认只有本地存储：图片存在服务器硬盘上，访问走图床自己的域名。初期够用，跑上几个月就会撞上三堵墙：磁盘满、备份难、被盗链烧流量。多存储策略就是把"图片存哪"拆开：本地存高频小图，对象存储存大图和冷数据，不同用户组走不同策略。再配上防盗链，链接只能在自己的站上用。本文基于兰空图床 2.x 实测，部署环境是群晖 + 宝塔上的 Docker 容器。基础安装和粘贴上传插件的用法见旧文：利用兰空图床更加快捷的进行图片传输。二、先搭好"分流"，再谈配置2.1 兰空支持哪些存储Lsky Pro 2.x 内置的存储策略分四类：存储类型适合场景成本参考本地存储小图、封面、高频访问磁盘成本S3 兼容存储大图、原图、冷备份R2 有免费额度，OSS/COS 按量FTP / WebDAV已有现成存储空间看原有空间其他对象存储七牛、又拍云等按量计费我的实际分法是：文章配图走本地（访问快、备份跟着整站走），大文件和原图走 S3 兼容存储（不占 VPS 磁盘）。这样 VPS 磁盘常年保持在安全水位，图片丢了也能从对象存储侧找回。2.2 新增一条 S3 兼容存储策略以 Cloudflare R2 为例（免费额度对个人站很友好）：登录兰空后台，进入「管理 → 存储策略 → 添加策略」。存储类型选「AWS S3」（R2 兼容 S3 协议，用这个类型）。按 R2 后台给的参数逐项填写：Access Key / Secret Key（在 R2 的「管理 R2 API 令牌」里创建，只给当前 Bucket 的读写权限，不要用账号级密钥）、Endpoint（形如 https://<account-id>.r2.cloudflarestorage.com）、Bucket（提前建好的桶名）、Region（填 auto）、自定义域名（绑自己的子域名，如 img.yeyhome.com，并在 R2 侧开启公共访问；不要直接用 *.r2.dev 默认域名，它有访问频率限制）。保存后点「测试连接」，返回成功再启用。测试失败先看 Endpoint 和密钥有没有多打空格，这是最常见的错。实测提醒：自定义域名一定要走 HTTPS。R2 侧绑定域名后要等证书签发完成再测，否则图片能上传、打不开，排错会绕大弯。2.3 策略怎么分流默认策略：后台「设置 → 上传配置」里指定，所有不指定策略的上传都走它。我把默认策略设为本地，保证博客配图的速度。按用户组分配：给不同用户组绑定不同策略，比如管理员走本地、普通访客走对象存储，避免公开上传把本地磁盘灌满。上传时指定：API 上传可带 strategy_id，Typecho 粘贴上传插件的设置里也有这个字段（见旧文），需要分流的场景直接填策略 ID 即可。三、防盗链：三道防线，别只靠一道防盗链没有银弹，我的实测结论是：图床后台鉴权 + Nginx Referer 校验 + 对象存储侧防盗链，三道一起上，单道被绕过也不至于裸奔。3.1 第一道：开启 URL 签名兰空支持图片 URL 签名（后台「设置 → 图片鉴权」相关选项，不同版本位置略有差异）：开启后链接带有效期签名，过期自动失效。代价是 CDN 缓存命中率会下降，我的做法是博客正文配图不签名（需要长期稳定、被 CDN 缓存），临时分享的大文件链接才签名，分场景取舍。3.2 第二道：Nginx Referer 白名单（最常用）图床前面如果有 Nginx 反代（我的图床就是宝塔 Nginx 反代到容器），加一段 Referer 校验最直接：location ~* \.(jpg|jpeg|png|gif|webp)$ { valid_referers none blocked server_names *.yeyhome.com yeyhome.com; if ($invalid_referer) { return 403; } }注意两点：none 允许直接访问（浏览器地址栏打开、RSS 阅读器等场景需要），不要把 none 去掉，否则自己的 RSS 订阅和微信里点开图片都会 403；白名单要写全，通配符 *.yeyhome.com 别漏。改完重载 Nginx（nginx -s reload 或宝塔面板点重载），用无痕模式测一遍。验证方法，用 curl 模拟盗链：# 模拟自己站引用，应返回 200 curl -I -e "https://www.yeyhome.com/" https://lsky.yeyhome.com:8666/i/2026/11/09/xxx.png # 模拟外站盗链，应返回 403 curl -I -e "https://evil.example.com/" https://lsky.yeyhome.com:8666/i/2026/11/09/xxx.png3.3 第三道：对象存储侧防盗链走 S3 兼容存储的图片，Nginx 那道防线管不着（流量直接走对象存储域名），要在对象存储侧再设一道：R2 在 Bucket 设置里配 Referer 白名单或用 Worker 做鉴权；阿里云 OSS / 腾讯云 COS 控制台直接有「防盗链」设置，填白名单域名即可。注意：对象存储侧的白名单要把图床域名和博客域名都加上，否则图床后台预览图自己都打不开——这个坑我踩过，排查了半小时才发现是白名单漏了图床自己的域名。四、实测结果：盗链前后对比场景开启前开启三道防线后本站文章内图片正常显示正常显示外站直接引用图片链接正常显示（被白嫖）403，显示破图微信内点开图片正常显示正常显示（空 Referer 放行）RSS 阅读器加载图片正常显示正常显示盗链者伪造空 Referer 抓取正常显示仍能打开（已知局限）最后一行是实话：Referer 防盗链防的是"随手引用"的君子，防不住刻意伪造 Referer 的爬虫。真要防死，得上 URL 签名 + 短期有效期，但那会牺牲 CDN 缓存和 RSS 体验。个人小站做到"随手引用打不开"这个程度，性价比最高。五、避坑清单删策略不等于删图片：后台删除存储策略只删配置，对象存储桶里的文件还在。换策略前先确认图片已迁移或不再需要。密钥只给最小权限：R2 / OSS 的 API 密钥只授权当前 Bucket 的读写，别用账号级密钥，泄露了别人能清空整个桶。自定义域名先配 HTTPS 再启用：对象存储绑定域名后证书签发要几分钟，证书没好就启用策略，图片能传不能看，报错还不直观。签名和 CDN 缓存冲突：开了 URL 签名又套了 CDN，缓存键要包含签名参数，否则 CDN 会把带旧签名的图片缓存下来，过期后全站破图。插件里的策略 ID 要同步改：Typecho 粘贴上传插件里填了 strategy_id 的，换策略、删策略后记得同步更新，否则上传会报策略不存在。本地磁盘也要留监控：多策略不等于不用管本地盘。本地策略的图片继续增长，配合群晖的存储空间告警设个阈值，备份思路见旧文：群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好。六、怎么回退与卸载进阶配置都是可逆的，不用怕改坏：切回单策略，把默认策略改回本地，新上传就走本地，已存对象存储的图片链接不受影响；删除多余策略，后台直接删，文件保留在对象存储桶里，之后手动清理桶即可；关掉防盗链，Nginx 那段配置注释掉并重载，对象存储侧白名单清空，立刻恢复开放访问；彻底停用图床，先导出图片清单（后台图片管理可按策略筛选），再把各策略桶里的文件下载备份，最后停容器、删目录——图片外链会随之失效，博客正文要批量替换回本地路径，所以大图上对象存储之前，先想好这一步。写在最后多存储策略和防盗链，本质上都是"图床长大之后"的必修课：存储要分流、流量要设防、密钥要最小权限。配置本身不复杂，复杂的是想清楚自己站点的图片分哪几类、每类走哪条路、每条路配什么防线。配好之后，图床就能从"能用"变成"耐用"——磁盘不爆、流量不被白嫖、换策略也不慌。相关旧文利用兰空图床更加快捷的进行图片传输（基础篇：安装与粘贴上传插件）群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好（图片数据的备份思路）Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选（图床内网访问与反代相关）

为什么放弃 FRP 选了 Lucky：一次工具选型心路 为什么放弃 FRP 选了 Lucky：一次工具选型心路家里这台群晖 NAS 跑了三四年，上面挂的东西越来越多：博客、相册、文件分享、下载器、监控面板，全都要从外网访问。内网穿透这件事，我最早用的是 FRP，后来换成了 Lucky。不是 FRP 不好，而是我的需求变了，工具没跟上。这篇不讲部署步骤，只讲一次真实的选型心路：当初为什么选 FRP、后来哪里不顺手、换 Lucky 之前我列了哪些需求、又是怎么验证的。如果你也在 FRP 和 Lucky 之间纠结，希望这篇能帮你少走点弯路。一、先说背景：我用 FRP 的那两年2024 年刚把博客和几个服务搬上 NAS 时，我用的是 FRP。老牌开源方案，文档全、教程多，群晖上用 Docker 跑一个 frpc 客户端，配好 frpc.ini，指向一台有公网 IP 的 VPS，几分钟就能把服务穿出去。那两年 FRP 跑得很稳，博客、相册、文件分享都走它，VPS 上一个 frps 服务端带五六个隧道，没出过什么大问题。说实话，如果需求一直停在“穿出去就行”，FRP 完全够用，我也不会换。转折点出现在服务越挂越多之后。每次加一个新服务，都要改 frpc.ini 加一段配置、重启容器、去 VPS 上确认端口。改一次两分钟，不麻烦，但改十次就烦了。更关键的是，有一次我手滑把配置文件里一个端口写错，重启后博客和相册一起断了，排查了半小时才发现是自己改错了行。那一刻我意识到：问题不是 FRP 不稳定，而是我的使用方式已经超出了“改配置文件”这种模式的舒适区。我需要一个能看得见、改得快、出错能立刻发现的管理方式，而不是每次靠文本编辑器和重启碰运气。二、换之前，先把需求写下来选型最忌讳凭感觉。换之前，我先把自己的真实需求列了一张表：多服务、多域名：NAS 上七八个服务，每个都要独立域名和 HTTPS，不能共用一个端口硬凑。改配置要快：加一个服务、改一个端口，最好在网页上点几下就完成，不用 SSH 进容器改文件、重启。证书要自动：HTTPS 证书到期要自动续，不能靠我每三个月想起来手动续一次。能看到状态：哪个隧道通、哪个断了、流量走了多少，最好一眼看得到，出问题不用先猜。维护成本低：家里这台 NAS 是 7×24 小时跑的，我不想每周都花时间伺候穿透工具，越省心越好。留退路：新工具如果水土不服，要能在一小时内切回 FRP，不能把全家服务押在一个没验证过的方案上。列完这张表我才发现，FRP 能满足前两条的一半：它能穿多服务、也能配 HTTPS，但“改配置要快”“能看到状态”“证书自动”这三条，它天生就不擅长。FRP 的设计哲学就是“配置文件即全部”，稳定、透明、可脚本化，代价就是一切都要手改文件、重启生效。这不是 FRP 的缺点，是它的定位。只是我的需求变了。三、为什么是 Lucky，不是别的当时摆在我面前的选择有三个：继续用 FRP、换 Lucky，或者试试 ECH（Cloudflare 隧道那套）。三者我之前都实测过，结论写在《Lucky / FRP / ECH 三种内网穿透实测对比》里：延迟上 FRP 和 Lucky 差不多，ECH 免费但节点和稳定性要看运气。这次选型我换了一个判断标准：不再只比延迟和成本，而是按上面那张需求表逐项打分。改配置：Lucky 带 Web 界面，端口转发、反向代理、域名绑定都在网页上点几下完成，改完即时生效，不用重启容器，直接命中我最痛的地方。证书：Lucky 内置 ACME 自动申请和续期，域名解析过去之后，证书自己申请、自己续期。我之前为证书单独写过同步脚本，换了 Lucky 之后那套脚本直接退役了。状态可见：Lucky 的管理界面能看到每条转发规则的状态，断了就是断了，不用先 SSH 再查日志。反代能力：Lucky 本身就是一个反向代理，多域名、多服务、路径分流都能在一个地方配齐，NAS 上的服务统一从它进出，架构反而比“FRP 穿透 + 另外一个反代”更简单。成本：Lucky 和 FRP 一样开源免费，部署同样是 Docker 一个容器，迁移成本就是把规则从配置文件抄到网页上，一个晚上能做完。ECH 我认真考虑过，但它依赖 Cloudflare 的网络，对我这种要稳定访问家里摄像头和 NAS 管理界面的场景来说，多一层不确定因素。免费是真免费，不可控也是真不可控。我的结论是：ECH 适合做备用通道，不适合当主力。所以最后的决定是：主力切到 Lucky，FRP 的服务端和客户端配置原样保留一个月，当作回滚预案。四、切换过程：一个晚上，平滑完成切换我分了三步走，没敢一次性全切：第一步：先搭 Lucky，不动 FRP。 在群晖 Container Manager 里新建一个 Lucky 容器，先把一个不重要的服务（下载器的 Web 界面）切过去跑两天，验证反代、HTTPS、证书续期都没问题。第二步：逐个服务迁移。 按“先边缘、后核心”的顺序迁移：先是文件分享、监控面板这类影响小的，最后才是博客和相册。每个服务切过去后，立刻从外网打开验证一遍，确认没问题再迁下一个。整个过程里 FRP 一直在跑，任何一个服务出问题，改回域名解析就能立刻恢复。第三步：观察两周，再拆 FRP。 全部服务切完后，我没有马上删 FRP，而是让它空跑了两周。这两周里 Lucky 经历了两次 NAS 重启、一次宽带断线重拨，都自动恢复了，证书也正常续了一次。确认稳定后，才把 FRP 的容器停掉，配置文件备份存档。整个切换没有一次全家断网，最长的一次单服务中断是博客切域名解析的几分钟，还是我自己手快改错了记录，改回来就好了。五、用了半年之后，诚实地说说 Lucky 的短板选了 Lucky 不代表它完美。用了半年，短板也得如实写出来：界面是强大，但也是负担：Lucky 的功能非常多，第一次打开管理界面，菜单密密麻麻，新手容易不知道从哪下手。FRP 的配置文件虽然原始，但至少一眼能看全。出了问题，排查要进界面：FRP 出问题看日志文件就行，Lucky 出问题要先打开管理界面，再找对应的规则和日志。对习惯命令行的老手来说，这一步反而多绕了一圈。版本更新要自己盯：Lucky 更新不算频繁，但也没有 FRP 那种“几年不动也稳”的气质。大版本升级前，最好先看一眼更新说明，别无脑点更新。这三条没有一条是致命的，但如果你是那种“配好一次、五年不碰”的用户，FRP 反而更合适。工具没有高下，只有适不适合当下的你。六、我的结论：选型看需求，不看名气这次选型最大的收获不是“Lucky 比 FRP 好”，而是想明白了一件事：工具的优劣是相对的，锚点是你自己的需求清单。如果你只有一两个服务要穿透，配置改得少，FRP 依然是最稳、最省心的选择。如果你的服务越来越多，改配置越来越频繁，又想要证书自动续、状态一眼可见，那 Lucky 值得换。如果你追求零成本、不在乎多一层不确定性，ECH 可以当备用通道，但别当唯一主力。顺便提醒一句：站内 2024 年写的 FRP 客户端部署旧文（用 Docker 跑 frpc、接免费 FRP 服务那套）现在看流程还能跑通，但思路已经过时了——免费 FRP 服务的稳定性、端口限制和现在的需求对不上号，如果你是新上手，建议直接按本文的思路先列需求、再选工具，不要照着旧文一步步抄。选工具和选人一样，没有完美的，只有合适的。FRP 陪我跑了两年，功劳簿上有它一笔；Lucky 接过下一棒，是因为下一程的路变了。下一程路再变的时候，我还会再列一次需求表。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmllucky证书更新群晖自动同步：https://www.yeyhome.com/2026/10/25/296.htmlLucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案：https://www.yeyhome.com/2026/02/26/68.html群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家：https://www.yeyhome.com/2026/11/05/304.html

群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家 群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家很多老用户是从 DSM 6.x 一路升级上来的，Docker 套件里跑着三五个容器：下载器、相册、密码库、监控面板，几年都没动过。升级到 DSM 7.2 后，Docker 套件被 Container Manager 接替，名字变了、界面变了，不少人第一反应是：直接升级会不会把容器弄丢？先给结论：DSM 7.2 的 Container Manager 就是 Docker 套件的改名续作，底层还是 Docker，容器和镜像可以平滑带过来。但“可以带过来”不等于“点一下升级就万事大吉”。旧版里一些写法、路径和权限，在新版里会踩坑。本文按真实迁移顺序讲：先盘点、再备份、再动手，迁移完逐项验证，万一翻车还能原路退回。提醒：站内 2022-2023 年写的群晖 Docker / DSM 6.x 旧文（旧版 Docker 套件界面与操作）已过时，请以本文 DSM 7.2 Container Manager 的流程为准，不要再按旧截图一步步点。一、迁移前先盘点：你到底跑着什么别急着点升级，先把家底列清楚。打开旧版 Docker（或已升级后的 Container Manager），逐个记下来：每个容器的名字、镜像名和版本标签（比如 latest 还是带版本号的 1.2.3）端口映射：宿主机端口对容器端口，例如 8080:80数据卷：哪些目录映射到了 /docker/xxx，哪些是匿名卷环境变量：时区 TZ=Asia/Shanghai、PUID/PGID、密码、域名等网络模式：bridge 还是 host，有没有用到 macvlan自动启动：是不是随 NAS 开机自启最容易丢的是两类东西：一是写在容器内部、没映射出来的数据（比如只存在容器里的数据库），二是 latest 标签——你以为还是原来那个版本，重新拉取后其实已经是大版本更新了。盘点表建议直接写成一张表，迁移后逐项打勾。还有一个常被忽略的点：DSM 7.2 要求 Container Manager 的项目文件和旧版 Docker 的存储位置不完全相同，升级向导一般会保留数据，但如果你之前把 Docker 目录改过位置，或者用了非默认的共享文件夹，升级前一定要先确认 /volume1/docker（或你自己的目录）里每个应用的文件夹都在。二、备份：三份东西，缺一不可迁移的底气全来自备份。动手前做好这三份：容器配置导出：在旧版 Docker 里把每个容器的设置导出，或者用 docker-compose.yml 重写一遍。推荐后者——一份 compose 文件就是一份可复现的部署说明书，比在界面里点来点去可靠得多。数据卷备份：把 /docker 下每个应用的配置和数据文件夹完整复制一份到另一个共享文件夹或外接硬盘。像 Vaultwarden 的数据文件、Immich 的上传目录、下载器的配置文件，丢了就得重头来。Hyper Backup 快照：如果 NAS 上开了 Hyper Backup 或快照，迁移前手动做一次快照。这一步是给“整个迁移翻车”准备的后悔药。备份完别只放在原地：验证一下备份文件能不能打开、大小是不是正常。备份没验证过，等于没备份。三、正式迁移：按这五步走第 1 步：停容器，记状态先把所有容器停掉，不要在运行中直接升级。停之前截一张运行状态图，或者把 docker ps 的输出存下来，方便迁移后对照：原来跑着几个、现在跑着几个，一眼就能看出来。第 2 步：升级 DSM 到 7.2，安装 Container Manager在控制面板里把 DSM 升级到 7.2（如果还没升），然后在套件中心安装 Container Manager。安装完成后，旧 Docker 套件会被替换，容器列表应该还在——如果列表空了，先别慌，也别马上重建，先看第 5 步的排查。第 3 步：核对镜像与容器逐个核对：容器名、镜像、端口、卷映射、环境变量是不是和盘点表一致。重点看三处：端口冲突：DSM 7.2 的系统服务占用端口有变化，原来能用的端口可能被系统占了，容器起不来就先查端口。权限变化：DSM 7.2 对共享文件夹权限更严格，容器用户读不到映射目录时，表现常常是“容器起来了但数据是空的”或“写不进文件”，这时要去检查文件夹权限和 PUID/PGID。网络模式：host 模式的容器在新版里行为基本一致；bridge 模式下如果原来用了自定义网桥，要确认网段没有冲突。第 4 步：逐个启动，别一键全开不要图省事把所有容器一次性全启动。一个一个起，起一个、看日志、打开网页确认能访问，再起下一个。日志里出现 permission denied 多半是权限问题；出现 port is already allocated 就是端口冲突；出现 no such file or directory 往往是卷路径写错了。特别提醒：数据库类容器（比如带 MariaDB/Postgres 的应用）启动要慢一些，等它初始化完成再判断，不要看到一时打不开就反复重启。第 5 步：全量验证按盘点表逐项验证：网页能打开、登录账号还在、历史数据都在、定时任务在跑、外部访问（域名或内网穿透）正常。验证通过的打勾，有问题的记下来集中处理，不要带着疑问过夜——迁移当天的问题，当天最容易定位。四、最常见的五个坑坑 1：以为升级会自动转 compose，旧容器变成“孤儿”旧版用界面建的容器，升级后可能没有对应的项目文件，界面里能看到但不好批量管理。办法：趁这次迁移，把重要容器逐个整理成 compose 项目，放到 Container Manager 的“项目”里统一管理，以后备份、迁移都是一份文件的事。坑 2：latest 一拉取，大版本变了迁移时顺手点了“更新镜像”，结果应用从 1.x 升到 2.x，配置格式不兼容。原则：迁移先求稳，镜像版本先保持原样；等迁移验证通过了，再单独安排一次升级，并且升级前再备份一次。坑 3：数据卷路径大小写或斜杠写错Linux 路径区分大小写，/docker/Vaultwarden 和 /docker/vaultwarden 是两个目录。迁移时复制路径要原样粘贴，不要手打。坑 4：时区和时间不对，定时任务全乱套新容器如果忘了设 TZ=Asia/Shanghai，定时签到、备份、清理任务的执行时间会差 8 小时。建容器时把时区写进环境变量，顺手检查一次。坑 5：没留回滚路，翻车只能干瞪眼回滚路其实很简单：旧数据文件夹的备份 + 旧 compose 文件 + 旧镜像版本号。只要这三样在，删掉新容器、按旧配置重建，十分钟就能回到迁移前。迁移当天不要删备份，确认稳定运行一周后再清理。五、迁移后顺手做的三件优化迁移只是开始，DSM 7.2 的 Container Manager 有几个值得顺手用起来的地方：用“项目”管理：把 compose 文件放进项目里，改配置不用再进容器详情页翻，改完一键重新部署。资源限制写清楚：给下载器、相册这类吃内存的应用设个内存上限，避免某个容器失控拖垮整台 NAS。日志轮转别忘开：容器日志默认一直涨，时间长了能吃掉不少空间。在 compose 里加上日志大小限制，或者定期清理。六、结尾：迁移清单，照着打勾[ ] 盘点表已列好：容器、镜像版本、端口、卷、环境变量、网络[ ] 数据卷已备份并验证能打开，Hyper Backup/快照已做[ ] 旧容器已停止，DSM 已升到 7.2，Container Manager 已安装[ ] 容器逐个启动、日志无报错、网页能访问[ ] 登录、历史数据、定时任务、外部访问逐项验证通过[ ] 重要容器已整理成 compose 项目，备份保留一周再清理DSM 7.2 的这次改名，表面是换了个名字，实际是把 Docker 管理收进了更规范的项目制里。迁移本身不难，难的是不做盘点、不做备份就直接动手。按本文的顺序走一遍，大多数人一个晚上就能平滑搬完，第二天早上起来，容器还是原来那几个，只是管理方式更顺手了。相关旧文群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：https://www.yeyhome.com/2026/10/20/285.htmlDockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战：https://www.yeyhome.com/2026/10/17/276.htmlLucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmlVaultwarden 自建密码库：Docker 一键部署 + 多端同步实测：https://www.yeyhome.com/2026/10/16/273.html

青龙面板进阶：PT 签到之外还能自动干什么 青龙面板很多人是冲着 PT 签到装的，装完跑一个签到脚本就扔在那里吃灰。其实它本质上就是一台带可视化界面的“定时任务服务器”：能跑脚本、能定 cron、能看日志、能发通知。签到只是它最不起眼的一种用法。这篇是之前那篇 PT 签到文的进阶篇，讲讲青龙在群晖 NAS 上除了签到，还能替你自动干哪些正经事，以及哪些坑别踩。青龙到底是什么，先说清楚青龙面板（Qinglong）是一个支持 Python、Node.js、Shell 等多种脚本的定时任务管理面板。你可以把它理解成“带界面的 crontab + 脚本仓库 + 日志查看器”：脚本往里一贴，执行时间用 cron 表达式一填，跑没跑、跑出什么结果，都能在面板里直接看到。它适合干的活有一个共同点：重复、定时、不需要人盯着。签到符合，备份、清理、巡检、提醒也都符合。反过来，需要交互、需要实时响应的活（比如远程桌面、在线聊天）就不适合它，别硬塞。如果你已经装过青龙，直接跳到下一节；还没装的，先用下面这段 Compose 在群晖 Container Manager 里起一个。Docker 一键部署在群晖上新建一个项目，docker-compose.yml 如下：services: qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - "5700:5700" volumes: - ./data:/ql/data environment: - QlBaseUrl=/部署要点只有三条：数据卷 ./data 一定要映射出来，否则容器一删，脚本、定时任务、环境变量全没了；端口 5700 别和已有服务冲突，冲突就改左侧端口，比如 5701:5700；首次打开 http://群晖IP:5700，按向导设好账号密码和通知方式（推荐 Bark 或邮件，巡检告警全靠它）。部署完先别急着往里塞脚本，先把下面这套“进阶用法”想清楚：你到底想让它替你省哪几件事。进阶用法一：多站点签到聚合，不止 PTPT 签到是起点，不是终点。很多论坛、网盘、工具站都有每日签到或每日任务，逻辑大同小异：登录、请求签到接口、判断返回结果、失败发通知。进阶的做法不是一个站点写一个脚本到处复制，而是一个脚本管一类站点：把账号、Cookie、签到地址放进青龙的环境变量，脚本只读变量不写死账号。新增一个站点，只加一组变量，不用改代码。实测步骤：在青龙「环境变量」里新建变量，如 SITE_COOKIE、SITE_SIGN_URL；在「定时任务」里新建任务，命令填 task 脚本名.py，cron 填 0 8 * * *（每天 8 点跑）；手动点一次「运行」，看日志里是“签到成功”还是“已签到”，确认无误再交给定时。提醒一句：签到脚本只用在你自己有账号、且站点规则允许自动签到的地方。有的站点明文禁止脚本签到，封号风险自担，别为了几个积分把主力账号搭进去。进阶用法二：NAS 自动运维，清理与备份交给它群晖用久了最常见的两件事：磁盘被 Docker 镜像、日志、缓存慢慢吃满；青龙自己的配置、脚本改了半天没备份。这两件都可以交给青龙自己干。定时清理 Docker 悬空镜像和日志，每周跑一次 Shell 脚本：#!/bin/bash # 每周清理一次悬空镜像，保留最近 7 天日志 docker image prune -f find /var/log -type f -name "*.log" -mtime +7 -delete 2>/dev/null echo "清理完成：$(date)"注意：这条脚本要在能访问 Docker 的宿主机定时任务里跑，或者把 Docker 套接字挂载进青龙容器——新手更稳妥的做法是把清理脚本放在群晖「任务计划」里，青龙只负责发提醒、记日志。别在没看懂命令的情况下直接 prune -a，会把没在运行的镜像也清掉，下次启动容器要重新拉取。定时备份青龙自身：把 /ql/data 打包一份，拷到群晖的备份目录或异地备份路径。备份方案本身可以参考本站的 3-2-1 备份思路：本地一份、快照一份、异地一份，青龙数据虽小，丢了却最麻烦——因为所有定时任务都在里面。进阶用法三：服务存活巡检，挂了第一时间知道Uptime Kuma 是专门的监控面板，青龙则适合做“轻量巡检 + 动作联动”。比如每 10 分钟 curl 一次家里的几个关键地址：博客首页、图床、NAS 的 Web Station 页面，状态码不是 200 就通过 Bark 推送告警。import requests URLS = [ "https://www.yeyhome.com/", "http://群晖内网IP:5000/", ] for url in URLS: try: r = requests.get(url, timeout=10) print(url, r.status_code) except Exception as e: print(f"告警：{url} 访问失败 {e}")把告警逻辑接上通知渠道后，巡检就从“偶尔想起来看一眼”变成了“挂了手机立刻响”。它和 Uptime Kuma 不冲突：Kuma 看得细、看板好看，青龙胜在顺手——巡检发现问题后，可以直接在同一个面板里再跑一个重启、清理脚本，形成“发现—处理”的闭环。进阶用法四：定时提醒与数据汇总还有一类活，青龙做起来比手机闹钟靠谱：每天固定时间汇总一件事，推到你面前。每天早上 8 点，把昨天各站点的签到结果汇总成一条推送；每周一，把 NAS 磁盘占用、Docker 容器状态汇总成一条周报；每月 1 号，提醒自己检查证书到期、域名续费、VPS 账单——这些事不难，难的是记得。实现方式都一样：脚本跑完把结果拼成一句话，调用 Bark 或邮件通知接口发出去。关键是只推值得看的：巡检正常时别天天推“一切正常”，只在异常或汇总节点推，否则推送一多，人就自动忽略了，等于没装。进阶用法五：脚本管理规范，别让面板变成垃圾场青龙用半年，面板里脚本一多就乱。进阶玩家的分水岭不在脚本写得多花哨，而在管理得干不干净。我的规矩是四条：命名规范：站点_用途.py，如 pt_sign.py、nas_cleanup.sh，一眼知道干什么；变量与代码分离：账号、Cookie、Webhook 地址一律放环境变量，脚本里不出现明文密钥，分享、迁移都不怕；依赖单独记：Python 脚本用到的第三方库，在青龙「依赖管理」里装好并记在脚本头部注释里，换机器重装不抓瞎；日志定期清：青龙日志默认越攒越大，定时任务里加一条每月清理旧日志的任务，别等磁盘告警才想起来。避坑清单：这几条都是实测踩过的时区先对齐：青龙容器时区默认可能是 UTC，cron 按 UTC 跑，想每天 8 点跑却 16 点才跑，先检查容器时区和群晖时区是否一致；别跑来路不明的脚本：网上“复制粘贴即用”的青龙脚本，先看它读了哪些变量、往外发了什么请求，再决定跑不跑；要你填账号密码的脚本，先确认它发到哪里；失败要通知：定时任务只设成功路径等于没设，脚本里把异常分支也接上通知，跑失败了你得知道；先手动跑一次：任何新任务上线前，先手动运行一次、看日志、确认输出，再交给定时。直接上定时，出问题都不知道是哪天开始坏的；别用青龙干重活：转码、压缩、大文件同步这类吃 CPU 和 IO 的活，交给群晖任务计划或专门工具，青龙只做轻量调度。怎么卸载：干净收尾哪天不想用了，卸载分两步：先停容器、删容器，再决定数据卷留不留。docker compose down # 数据也不要了，再加 -v： # docker compose down -v只 down 不加 -v，数据卷还在，以后重新 up 还能恢复；确认彻底不用，再加 -v 连数据一起清掉。卸载前如果脚本里有自己写的通用工具，先导出一份存到群晖的文档目录，别跟着容器一起删了。结语青龙的价值不在它能跑多少脚本，而在它把“每天、每周、每月都要做一次的小事”从你的脑子里接过去。PT 签到只是入门，从签到聚合、NAS 运维、服务巡检到定时汇总，一台群晖 + 一个青龙，就能搭起一套不用人盯着的家庭自动化小中枢。先从一个巡检任务开始跑通，跑稳了再往上加，别一次塞十个脚本——自动化最怕的不是少，而是乱。相关旧文：青龙面板 PT 站点自动签到脚本Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好

个人小站 4 年生存手记：成本、流量、为什么还在写 个人小站 4 年生存手记：成本、流量、为什么还在写前几天收到域名续费提醒，才意识到这个小站已经写了四年。四年不算长，但足够让一个人从“搭个博客玩玩”走到“每年固定要交一笔钱、固定要花一些晚上”，也足够看清一件事：个人小站活不活得下来，跟写得好不好关系不大，跟成本算没算清、预期放没放对关系很大。这篇不讲情怀，只摊账本、摊流量、摊教训。如果你也想开一个自己的小站，或者已经开了一个正在犹豫要不要续费，希望这篇能帮你少纠结一点。四年花了多少钱先说结论：养一个文字为主的小站，一年固定支出并不高，但“一次性投入”和“看不见的成本”最容易被低估。项目大致年支出说明域名几十元一年一续，续费价比首年贵，买之前先看续费价服务器/主机0～几百元站点跑在自家 NAS 上，电费和宽带是分摊成本；租 VPS 则是明码标价备份硬盘/对象存储一两百元备份不是可选项，丢一次数据的代价远超这点钱图床与 CDN几乎为 0图片走自建图床，流量不大时没必要上付费 CDNHTTPS 证书0 元Let's Encrypt 免费证书 + 自动续期，不用买付费证书把账摊开看，一年固定支出基本在“一顿饭到几顿饭”之间。真正贵的是最初那一下：NAS、硬盘、路由器、UPS，这些设备钱不能算进“博客成本”，因为它们本来就是家里在用的基础设施；但如果只为了写博客去买一整套，那就纯属本末倒置。还有一笔看不见的成本：时间。一篇实战教程从动手、截图、整理到发布，常常要花两个晚上。四年下来，时间成本远高于金钱成本。想清楚这一点，后面很多决定就好做了——凡是不能复用、不能沉淀的东西，都不值得花两个晚上。流量真相：没有爆款，但有长尾上图为流量走势示意图，非真实统计数据。小站的流量曲线从来不是一路向上的直线，更像心电图：平时平稳，偶尔因为一篇教程被搜到而抖一下，然后回落。四年看下来，规律很清楚：教程类长尾最稳。 一篇把步骤、报错、回滚都写全的部署教程，哪怕当时没什么人看，之后几年会陆陆续续被搜到。热点文则相反，来得快去得也快。搜索来的读者最实在。 他们是带着具体问题来的，打开、照着做、做成了就走，跳出率高但转化真实——评论区一句“按这个步骤成了”，比一万个泛泛的访问量都有用。流量低谷是常态，不是失败。 有那么几个月，几乎没什么新访问，文章也写得断断续续。后来发现，低谷期恰恰是整理旧文、修死链、补备份的最好时机。所以我现在对流量的预期放得很低：不追爆款，不蹭热点，只保证每篇都是“半年后搜到还能照着做”的东西。流量可以慢慢攒，信任攒起来更慢，丢起来却很快。四年踩过的坑，浓缩成四条第一，备份先行，发布在后。 早年有一次折腾主题把站点搞挂，幸好有整站备份，半小时就恢复了。从那以后，备份成了铁律：本地一份、异地一份，恢复流程每年至少演练一次。具体做法见《群晖 3-2-1 备份方案》那篇，思路至今没变。第二，能自建的先自建，能免费的先免费。 域名、证书、图床、统计，这些基础件都有免费或自建方案。先把免费路线跑通，真的不够用了再付费升级，顺序反过来最容易花冤枉钱。第三，旧文要维护，不是写完就完。 2022-2023 年那批群晖 Docker、DSM 6.x 的旧文，现在看很多步骤已经过时。我正在陆续给它们标注“已过时”并链到新版教程，不让搜到的读者按旧步骤踩坑。写新文之前，先翻一遍站内旧文有没有冲突的说法，这已经成了动笔前的固定动作。第四，别为了更新而更新。 有一段时间给自己定了“每周一篇”的死线，结果写出来的东西自己都不想看第二遍。后来改成“有值得记的东西再写”，更新慢了，但每篇都更扎实。个人小站没有 KPI，写作者自己先厌倦了，站点也就死了。为什么还在写写了四年，问过自己很多次这个问题，答案其实每年都在变。第一年是新鲜感，第二年是想记录折腾过程，第三年开始，是因为真的有人照着文章把东西搭起来了，评论区会回来报一声“成了”。更实际一点说，写博客是给自己建了一个可检索的笔记本。门禁怎么接线、Lucky 和 FRP 怎么选、备份怎么恢复——这些东西当时折腾明白了，不记下来半年就忘。写下来，既是分享，也是给未来的自己留一份说明书。还有一个原因：小站是少数完全属于自己的地方。不用看平台脸色，不用追算法，标题、排版、链接都自己说了算。这种掌控感，是所有第三方平台都给不了的。给想开小站的人三条建议先算年成本，再动手。 把域名续费价、主机或电费、备份成本列出来，能接受这个数再开站，别等续费时才肉疼。选自己能长期维护的技术栈。 轻量、备份方便、出了问题能自己修，比功能花哨重要得多。这也是本站从 WordPress 转到 Typecho 的原因。第一篇不用完美，但要真实。 把你刚解决的一个具体问题写清楚，就是最好的开局。完美主义是开站最大的敌人。四年下来，这个小站没赚过钱，也没爆过款，但它一直在，而且一直在被需要。这就够了。下一个四年，继续写，继续修旧文，继续把账算清楚。相关旧文从 WordPress 到 Typecho：一个小站长的博客轻量化转型记群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选

弱电工程实战：可视对讲 + 门禁 + 网络布线联调 前言：三个系统单独都通，一联调就全乱弱电工程里最磨人的，从来不是单个设备调不通，而是可视对讲、门禁、网络布线三个系统凑到一起之后，互相扯皮：对讲一按就断网，门禁一刷卡对讲就花屏，交换机一重启，门口机和室内机全掉线。我之前做过一个小项目：门口机、室内机、门禁控制器、摄像头、NAS、交换机全齐了，单测每个都正常，联调当天却花了大半天才捋顺。事后复盘，问题不在设备，而在顺序——没有按“先物理、再网络、再单系统、最后跨系统”的顺序走，一上来就全系统联调，出了问题根本不知道是哪一层。这篇就是那次联调的完整复盘：联调顺序、每一步的验收标准、以及一张排障表，照着走能省下至少半天返工。一、联调之前，先把三件事定死联调最怕边调边改方案。动手前，先把下面三件事落在纸上，现场只执行、不讨论。1. 一张拓扑图，而不是脑子里的一张图画清楚：光猫 / 路由 / 核心交换机 / 楼层交换机 / POE 交换机分别在哪，门口机、室内机、门禁控制器、摄像头、NVR、NAS 各接哪个口、拿什么地址。地址规划建议单独给弱电留一个网段，例如 192.168.10.x，门口机、室内机、门禁控制器按设备类型分段，DHCP 只给临时调试用，正式交付前全部改静态地址。地址一乱，联调时抓包都不知道谁是谁。2. 供电方式先定，不要现场现想可视对讲门口机、门禁电锁、摄像头这三类最容易在供电上翻车：POE 供电的摄像头和门口机，要核对交换机 POE 总功率够不够；电锁必须独立电源，绝对不要从门禁控制器板子上直接取电带锁——锁一动作电流一冲，控制器重启，对讲跟着掉线。电锁电源建议单独一路，带 UPS 更好，断电时门该开还是该关，提前和业主确认好（消防通道与安全门的逻辑是反的，不能凭感觉定）。3. 线材与标签一次到位六类线跑千兆、超五类线只跑百兆，这个账要在布线时算清，不要等联调测速时才发现瓶颈。每个信息点、每个弱电箱出线都要贴标签：哪根线去门口、哪根去门禁、哪根去摄像头。没有标签的联调，就是在几十根线里玩抽奖。二、联调顺序：五步走，跳步必返工记住这个顺序：物理层 → 网络层 → 单系统 → 跨系统 → 验收。任何一步没验收通过，不要进下一步。第一步：物理层——线通了再说别的先测线：测线仪打通每根网线，确认线序、通断、POE 供电正常；再测电：电锁电源、门口机电源、交换机电源逐一上电，量电压。门禁的线重点查四组：电源线、信号线（读卡器 / 出门按钮）、电锁线、门磁线。上一篇文章里讲过的门禁接线，这里不再展开，联调时只要确认这四组线没有接反、没有虚接。第二步：网络层——先 ping 通，再谈业务所有设备上电后，先做三件事：ping 网关、ping 核心交换机、ping 同网段的其他弱电设备；再看交换机端口速率是不是千兆、POE 功率有没有超标；最后把 VLAN、端口隔离（如果用了）核对一遍。网络层不通就去调对讲参数，是联调最常见的无效劳动。第三步：单系统自测——各自先跑起来可视对讲单独测：门口机呼叫室内机、室内机开锁、门口机夜视；门禁单独测：刷卡开门、出门按钮开门、门磁报警、断电状态；网络单独测：摄像头上 NVR、NAS 能访问、远程访问走内网穿透是否正常。单系统自测时发现的问题，修起来最便宜，因为干扰项最少。第四步：跨系统联调——按真实使用场景走一遍这一步不要只测“功能”，要测“场景”：访客按门口机 → 室内机振铃 → 业主开锁 → 门禁记录同步；业主刷卡进门 → 摄像头抓拍联动 → NVR 留下记录；断电再来电 → 各系统按什么顺序恢复、要不要手动干预。场景走通了，才算联调通过；只测单点功能通过，交付后照样会在真实场景里翻车。第五步：验收与留档联调记录要留下来：每台设备的 IP、账号（密码单独保管）、固件版本、接线照片、拓扑图最终版。交付时给业主一份简化版：出问题先看哪盏灯、重启顺序是什么、哪个口不能乱拔。没有留档的工程，下次上门维护等于重新做一次勘察。三、排障表：联调现场最常见的六种翻车现象先查什么常见根因门口机呼叫时断时续交换机 POE 功率、网线长度与线序POE 总功率超标，或超长线 + 劣质水晶头导致协商降速室内机能振铃但开不了锁电锁电源、开锁继电器接线锁电源与控制器共用一路，锁动作瞬间拉垮电压刷卡正常但记录不同步门禁控制器 IP、网关、NTP 时间控制器拿了 DHCP 临时地址，重启后变了；或时间不同步导致记录对不上摄像头一多，对讲就卡交换机背板带宽、是否跑满百兆口摄像头与对讲挤在同一个百兆口 / 同一台低端交换机上断电恢复后部分设备掉线各设备启动顺序、DHCP 租期门口机比交换机先启动，拿不到地址；或 DHCP 冲突远程能看摄像头，打不开对讲内网穿透 / 端口映射规则只映射了摄像头端口，对讲的信令端口没放行排障有个通用原则：先分层定位，再换件验证。先确认是线的问题、网络的问题还是设备参数的问题，再去动配置；一上来就恢复出厂设置，往往会把原本正常的参数也洗掉，越修越乱。四、几个容易被忽略的细节门口机与室内机固件版本要一致：跨版本联调最容易出“能呼叫、不能开锁”这种半通不通的怪现象，联调前先统一升级。门磁一定要装：没有门磁，门禁系统不知道门到底关没关，联动和报警全是摆设，验收时也说不清楚。弱电箱留余量：交换机端口、电源插座、线槽空间都留 20% 以上余量，今天多留一个口，明天加个摄像头就不用重新布线。防雷与接地别省：室外门口机、室外摄像头的外壳接地和防雷器，省下来的是成本，赔进去的是整机。标签与图纸随工程走：拓扑图最终版贴在弱电箱门内侧，下次任何人上门，打开箱门就知道线怎么走。五、验收清单（照着打勾就能交）[ ] 每根网线测线通过，标签与图纸一致[ ] 门口机 ↔ 室内机呼叫、开锁、夜视全部正常[ ] 门禁刷卡、出门按钮、门磁报警、断电状态全部验证[ ] 摄像头上 NVR、NAS 远程访问、内网穿透全部正常[ ] 断电再来电后，各系统自动恢复，无需手动干预[ ] 拓扑图、IP 表、账号清单已留档并交给业主联调这件事，拼的不是谁手速快，而是谁的顺序对。按物理层、网络层、单系统、跨系统、验收这五步走，问题出现在哪一层，就在哪一层解决，不要跨层猜。希望这篇能帮你在下一个项目里，联调当天准时收工。相关旧文一个门禁项目的布线到调试踩坑手记：门禁四组线的接法与调试细节，这篇联调的前提。群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战：摄像头上 NVR 与存储联动的工程视角。Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：远程访问走哪条穿透路线，联调前先定好。群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：联调留档与录像备份的配套思路。

MkLetterAvatar：Typecho 评论区自动生成昵称首字头像 MkLetterAvatar：Typecho 评论区自动生成昵称首字头像前言：评论区为什么总是灰色头像用 Typecho 建站的朋友大概都遇到过这个场面：评论区里一片清一色的灰色小人剪影，或者干脆裂图。原因很简单——Typecho 默认用 Gravatar 显示评论头像，而绝大多数访客根本没有注册过 Gravatar，Gravatar 在国内访问还经常抽风，头像就只能显示默认图，难看不说，还分不清谁是谁。今天分享的这个插件就是解决这个问题的：MkLetterAvatar（Typecho 版）。它会给没有头像的评论者自动生成一张“昵称首字头像”：彩色底 + 昵称第一个字，每个人的颜色按名字固定，一眼就能分清谁是谁，评论区立刻有了人味。干什么用一句话：没头像的评论者，自动用昵称首字生成一张专属头像。具体效果是这样的：昵称首字：比如评论者叫“零距离”，头像就是彩色底上一个“零”字；叫 docker，头像就是一个字母 d。颜色按人固定：颜色是按昵称首字的编码从 20 色里取的，同一个人在所有文章下的头像颜色都一样，辨识度很高。有头像的人不受影响：注册过 Gravatar 的评论者继续显示自己的真实头像，插件不会动它。QQ 邮箱评论者不受影响：在 Joe 主题下，QQ 邮箱本来走 QQ 头像，插件同样不会动。不产生服务器缓存：头像完全在访客浏览器里用 Canvas 现场画出来，服务器上不生成任何图片文件，干净、省空间。体积小：整个插件只有一个 PHP 文件，不到 10KB。这个插件从哪来这个插件不是凭空写的，它有一条清晰的来源线：原版是 WordPress 插件 mk-letter-avatar，作者是孟坤（mengkun）。它的思路很巧妙：把头像地址的默认图参数改成 d=404 试探——有真实头像就正常显示，没有就让浏览器现场画一张字母头像。整个原版不到 5KB，纯前端实现。本站长把它 fork 到了自己的 GitHub（yeyinghai/mk-letter-avatar），作为这个小工具的落脚点。Typecho 版是在原版基础上移植的：WordPress 靠 get_avatar 过滤器改写头像标签，Typecho 没有这个过滤器，所以移植版把同样的逻辑搬到了前端——脚本随页面输出，先试探头像地址有没有真实头像，没有才换成字母头像。生成算法、颜色列表、只取首字、过滤 emoji 这些核心逻辑与原版完全一致，功能没有打折。也就是说：这是一个有年头的成熟思路，只是第一次被完整地搬到 Typecho 上。安装方法一共三步，不用改代码：下载插件包：点此下载 MkLetterAvatar.zip；解压后把 MkLetterAvatar 文件夹上传到 Typecho 的 usr/plugins/ 目录下（最终路径是 usr/plugins/MkLetterAvatar/Plugin.php）；进博客后台「控制台 → 插件」，找到「MK 字母头像」点启用，完事。启用后不需要任何设置，默认配置就能直接用。插件提供了两个可选设置项，需要时再动：头像图片选择器：默认 img.avatar。Typecho 默认主题和 Joe 主题的评论头像都是这个类名，一般不用改。头像背景颜色列表：默认 20 个颜色，空格分隔，可以按自己的喜好增删改。实测效果这个插件已经在本站（夜影小窝）启用并实测过。拿本站一篇有评论的文章看效果：未注册 Gravatar 的评论者，头像变成了彩色底 + 昵称首字；站长本人的真实头像保持不变；整个评论区的头像加载正常，没有裂图和空白。注意事项主题要支持页脚钩子：插件的脚本是挂在 Typecho 的页眉/页脚钩子上输出的，绝大多数主题（包括 Joe）都支持；极少数自定义主题如果没有调用页脚输出，插件会不生效，这种情况换回标准主题模板即可。头像源可以继续用 Cravatar：本站把头像源换成了 Cravatar，配合这个插件是最佳组合——有头像的拉真实头像、拉不到的现场生成字母头像、QQ 邮箱的走 QQ 头像，三条线互不干扰。换颜色立即生效：在插件设置里改了颜色列表后，刷新页面就能看到新颜色，不用清任何缓存（因为本来就没有缓存）。如果头像没有变化：先确认插件已启用，再看主题评论头像是不是 img.avatar 这个类名；如果主题用了别的类名，在插件设置里把选择器改成对应的类名即可。卸载方法同样简单：后台「控制台 → 插件」里禁用「MK 字母头像」，再把 usr/plugins/MkLetterAvatar/ 文件夹删掉，评论头像就恢复到启用前的状态，不会在数据库和服务器上留下任何东西。写在最后评论区是博客最有人气的地方，一排灰色默认头像实在煞风景。这个插件不改数据库、不占空间、不依赖外部头像服务，就让每个评论者都有了自己的脸。如果你也在用 Typecho，不妨装上试试。下载点此下载 MkLetterAvatar.zip（Typecho 版，解压后上传到 usr/plugins/ 启用）相关旧文Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实测 —— 博客常用自建服务之一Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 自建服务管理起来更顺手