为您搜索到
19
篇关于
随笔心得
的相关文章，期待您能满意而归！
-
为什么放弃 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 -
个人小站 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 三种内网穿透实测对比：延迟、成本、稳定性怎么选
-
Muse / Hark 用了一个月：真提效还是玩具 Muse / Hark 用了一个月：真提效还是玩具十月初，本站发了两篇 AI 助手的上手教程：一篇讲 Muse，一篇讲 Hark Pro。当时很多读者（包括我自己）的疑问都一样：看着很酷，用一个月后到底会不会吃灰？一个月过去了，两个应用我都保持了高频使用。今天不讲注册、不讲安装，就讲这一个月的真实复盘：哪些地方真省了时间，哪些地方是包装出来的“智能”，以及一个折腾 NAS、跑工程的人，到底该怎么用这类工具。先交代使用强度过去一个月，Muse 和 Hark 都装在我手机上，Muse 还开了浏览器插件并绑了几个常用应用。每天至少打开其中一个 3~5 次，Muse 的定时任务每天自动跑 4~5 个（包括本站的自动签到、定时提醒类任务），Hark 接了邮箱和日历。这不是实验室测评，是真实干活环境下的使用记录。真提效的三个场景场景一：弱电工程的方案和报价打底这是提效最明显的一块。做一个门禁或者监控项目，方案说明、设备清单、报价单格式大同小异但每次都要重写。现在我的流程是：把项目参数（点位数量、线缆长度、设备型号）丢给 Muse，它先出一版方案框架和报价表，我再逐项核对改数。注意，是“我再逐项核对”。AI 出的价格和型号配置不能直接发给甲方——它对某些小众设备型号的记忆是错的，价格也可能是去年的。我实测下来，它省掉的是“搭架子”的时间，一份原本要花两小时排版的报价单，现在大概 40 分钟能成稿，前提是你对设备和市场价足够熟，能一眼看出它哪里胡说。场景二：Docker / NAS 运维的排错搭子群晖 Container Manager 里容器起不来、反代报 502、docker-compose 语法报错——这类问题现在我先问 AI。它给出的排查思路大多靠谱：看日志、检查端口映射、核对环境变量。特别是半夜在现场、手机上没法开电脑的时候，口述症状让它给排查清单，比翻论坛帖快得多。但它给的命令一定要逐条理解再执行。别图省事直接复制粘贴，尤其带 --privileged、rm、chmod -R 的命令。AI 不会为你删掉的数据负责。场景三：长尾重复劳动的“外包”这是两个工具最被低估的价值。每天固定时间的提醒、多个站点的签到、定期汇总信息——这类事情单个不值钱，加起来却很耗神。我把这部分交给了 Muse 的定时任务：每天早上自动跑一轮，把需要我看一眼的结果推到手机上。这类任务的特点是：流程固定、判断简单、频率高。让 AI 当“值班员”，人只负责看结果和异常，恰好是它的舒适区。Muse 和 Hark，一个月用下来的分工两个工具的定位其实不一样，用下来自然形成了分工：Muse 像秘书兼助理：强项是“交办了就不用管”——定时任务、跨应用协作、把一个流程跑完再汇报。我给它定的规矩是：办完事才来找我，过程不打扰。Hark Pro 像主动的前台：强项是“提前想到”——读了邮箱和日历后，主动弹出待办卡片，点一下按钮就把事办了。它的 Handoff 云电脑可以代替人去点网页、填表单，比如帮你把某个网站的表格填完，只留最后确认付款给你。Hark 是 10 月 6 日才正式上线的（创始人是 Figure AI 的 Brett Adcock），目前免费可用，付费档 20 美元/月是 2 倍用量、100 美元/月是 10 倍用量。但坦白说，它还很早期：复杂任务经常比自己动手还慢，这一点连官方演示都承认。我的用法是把它当“提醒器 + 简单代办”，复杂的网页操作还是自己来。踩过的坑：玩具的部分第一，幻觉不分场合。 AI 生成的内容里，型号、价格、政策、接口参数是最容易错的。上个月它给我的一份设备清单里，有两个型号写错了后缀——外观一样的字，实际是停产的老款。这种错误不核对就发出去，丢的是自己的脸。我的原则：凡是会花钱、会发给别人、会动生产环境的输出，必须人工逐项核验。第二，隐私账要先算。 Hark 的主动能力建立在“读你的邮箱和日历”上。接之前先想清楚：你的邮箱里有没有不想让第三方模型读的东西？我最后只接了一个专门收通知的邮箱，工作主邮箱没接。方便和隐私永远是 trade-off，别为了尝鲜全盘托出。第三，免费额度消耗比想象快。 两个工具的免费档都够“体验”，但一旦把定时任务、主动提醒全开，用量涨得很快。我这一个月的结论是：免费档适合验证“这个场景值不值”，真要长期用在生产流程里，20 美元/月那档的心理门槛得先过——换算下来，差不多是每天一杯奶茶钱，值不值看它替你省了多少时间。第四，别指望它替你思考。 选型决策、工程方案的取舍、和甲方的沟通分寸，这些需要经验和责任的事，AI 给不出答案。它能做的是把信息整理好、把选项列清楚，最后拍板的人必须是你。成本复盘：这一个月花了多少钱如实交代：这一个月两个工具我都没付费，全程免费档。Hark 免费档覆盖了我的“提醒器”用法；Muse 免费档跑 4~5 个定时任务加日常问答，月底额度还剩一些。但如果把用法再加重——比如定时任务翻倍、让 Handoff 频繁代操作网页——免费档肯定不够。我的判断是：先按免费档跑一个月，统计它替你省了多少小时，再决定 20 美元/月值不值。别一上来就付费，也别因为免费就乱开任务把额度烧光。结论：副手，不是替手一个月用下来，我的结论很简单：它是真提效的场景：固定流程的重复劳动、写方案报价的打底、运维排错的思路参考、信息的整理汇总。它是玩具的场景：需要拍板的决策、涉及花钱和生产环境的操作、对准确性零容忍的输出——这些地方它只能当参谋，不能当主将。给同样折腾 NAS、跑工程的朋友一句话建议：把 AI 当成一个不用发工资、不用休息、但需要你逐条验收的实习生。验收成本省不掉，但它确实能把你的时间从重复劳动里抠出来，留给真正需要经验和判断的事。相关旧文：Muse AI 注册与使用教程：手把手教你拥有一个个人 AI 助理Hark Pro 注册与使用教程：体验“主动式”AI 助手
-
一个门禁项目的布线到调试踩坑手记 去年年底接了个小活：给一栋三层小办公楼做门禁，一共 6 道门——大门是磁力锁，办公室几道门用电插锁，机房单独一路。设备不复杂，一台四门控制器加一台双门控制器、几个 ID 读卡头、门禁专用电源，活不大，但从布线到调试，坑是一个没落下全踩了一遍。这篇就是那次项目的现场手记：报价怎么报的、线怎么布的、门禁那几根线到底怎么接、通电调试又是怎么排错的。重点把接线和调试讲透，这两块是门禁项目里最容易翻车的地方。一、报价：先把丑话说在前面门禁报价最容易吃亏的地方，是只报了设备钱，漏了辅料和人工。我那次的清单是这么列的：控制器、读卡器、电锁、出门按钮、门禁电源按"套"报；线材（RVV 2×1.0 电源线、超五类网线走韦根和网络）、线管、86 底盒、电源插座移位按"米/项"实报实销；人工按"门"计费，一道门多少钱写死。另外单独列了一条：旧门改造开孔、玻璃门开孔另计——玻璃门开孔要找专业师傅，电插锁在玻璃门上开孔打碎一块玻璃，赔的比赚的多。还有一条血泪经验：报价单里写清楚"调试含几次上门"。我当时没写，联调阶段跑了三趟，油钱和时间全是自己贴。建议写"含两次上门调试，超出按次收费"，丑话说前面，客户反而觉得你专业。二、布线：线放对了，后面少一半麻烦门禁的线分四种，每种走法不一样，千万别图省事一根管子全塞进去：电源线：从门禁专用电源到控制器、电锁，用 RVV 2×1.0（距离超过 30 米用 2×1.5）。电源线单独穿管，别和信号线挤一根管。信号线（读卡器线）：读卡器到控制器，用 8 芯网线或 6 芯屏蔽线。韦根协议的有效距离一般在 80~100 米以内，超了就换 485 读头。电锁线：控制器到电锁，RVV 2×1.0 即可，磁力锁功率大、距离远的话加粗到 1.5。出门按钮线 / 门磁线：RVV 2×0.5 或用网线中的余芯，按钮是开关量信号，要求不高，但要和 220V 强电分开走。布线阶段我踩的第一个坑：强弱电同管。有一路读卡器线和照明 220V 穿了同一根管，结果那只读卡器时灵时不灵，刷卡距离忽远忽近。返工单独穿管之后立刻正常。记住：门禁信号线离强电至少 30cm，能走桥架就走桥架。第二个坑：没留余量。有一道门线放短了 2 米，接线的时候只能在管里做接头。门禁的接头最怕受潮氧化，能一根线到头就一根线到头，宁可每端多留 1 米盘在底盒里。三、接线：全文重点，四组线一次讲透门禁接线就四组：电源线、信号线、电锁线、出门按钮线。控制器端子一般都丝印得很清楚，对着接就行，关键是理解每组线在干什么。1. 电源线：先给系统供上电门禁一定要用门禁专用电源（12V 3A~5A），不要拿普通的 12V 适配器凑合。专用电源带充电管理，可以外挂一块 12V 蓄电池，停电后门禁还能撑几个小时。接法：市电 220V 进电源，电源输出 12V 的 +12V / GND 接到控制器的电源端子。注意电锁的供电建议单独从电源上取一路，不要经过控制器转供——电锁吸合瞬间电流大，和控制器抢电会导致控制器重启、读卡器掉线，这是最常见的"一刷卡就重启"故障根源。2. 信号线：读卡器到控制器（韦根线）这是新手最容易接错的一组。标准韦根读卡器一般 6 根线，颜色各家略有差异，以说明书为准，常见对应关系：线色接控制器端子说明红+12V读卡器供电黑GND读卡器地线绿WG0 / DATA0数据 0白WG1 / DATA1数据 1棕BEEP蜂鸣器控制（可选）黄LED指示灯控制（可选）核心就四根：红黑供电、绿白数据。BEEP 和 LED 不接也能用，只是刷卡时没声音没灯。我当时有一只读卡器刷卡没反应，查了半天是绿白两根接反了——DATA0/DATA1 接反，控制器收到的全是乱码。接完先别急着上电，用万用表通断档把每根线从读卡器端打到控制器端确认一遍，5 分钟能省掉后面 2 小时的排查。3. 电锁线：NO / NC 是灵魂电锁线接的是控制器的继电器输出，一般标 NO（常开）、COM（公共）、NC（常闭）。选哪个，取决于你的锁是"断电开门"还是"通电开门"：磁力锁：断电开门（消防要求，断电必须能跑出去）。锁的正极接电源 +12V，负极经过控制器的 NC + COM 回到电源地。正常时 NC 闭合、锁得电吸住；刷卡开门时继电器动作、NC 断开，锁失电松开。电插锁：分两种，买之前先看说明书。断电开型（常用于通道门）接法同磁力锁、走 NC；通电开型（常用于机房、财务室，断电也要锁着）走 NO，刷卡时 NO 闭合、锁得电打开，延时几秒后断开重新锁上。我那次翻车就翻在这里：机房那道门买的是通电开型电插锁，我按习惯接了 NC，结果门一直是开的，刷卡反而把门锁上——正好反了。返工把线挪到 NO 端子上，5 分钟解决，但之前排查"为什么锁不上"花了一整个下午。记住口诀：要断电开门就走 NC，要断电锁门就走 NO。另外电锁两端建议并一个续流二极管（或压敏电阻），吸收锁线圈断电时的反向电动势，不然继电器触点打火，用半年触点就粘连了。很多控制器自带了保护，但外接一个更保险，几毛钱的事。4. 出门按钮线 + 门磁线：最简单的两组出门按钮：就是一个常开开关，两根线接控制器的 PUSH（或 BUTTON）和 GND。按下去 → PUSH 对地短路 → 控制器开门。没极性，随便接。门磁：门框上一片、门扇上一片，对齐安装，两根线接控制器的门磁检测端子。门没关好时控制器报警或提示，联动"门未关"提醒。出门按钮我踩过一个小坑：按钮装在了门内侧，但线是从门外侧绕过去的，装修师傅后期打孔差点把线打断。按钮线宁可走门内侧吊顶，也别贴着门框走明线，后期装修是门禁线的头号杀手。四、通电调试：按顺序来，别一股脑全上电调试我总结了一个固定顺序，一步过再走下一步：空载测电源：先不接任何设备，电源上电，万用表量输出是不是 12V（空载 12V 左右正常，13.8V 那是带充电的浮充电压，也正常）。控制器单机上电：只接电源线，看控制器指示灯、能不能进管理软件/网页。先把门参数、开门延时设好。逐个接读卡器：接一个、刷卡测一个。管理软件里能看到实时刷卡记录，卡号对得上说明韦根线没问题。最后接电锁：先不装锁体，拿万用表量继电器端子——刷卡瞬间 NO/COM 之间应该导通（或 NC 断开），确认逻辑对了再把锁装上。这一步能拦住 90% 的 NO/NC 接反问题。联调：出门按钮、门磁、消防联动（如果有）逐个测。消防联动一般是断电信号，测试时确认断电后磁力锁能正常释放。排错速查表（都是我亲手踩过的）：一刷卡控制器重启 → 电锁和控制器抢电，电锁单独取电或换大功率电源。读卡器时灵时不灵 → 查强弱电同管、韦根线超长、接头氧化。门一直开着 / 一直锁着 → NO/NC 接反，对照"断电开门走 NC"口诀。刷卡有记录但门不开 → 继电器没动作，查电锁供电回路、延时设置。出门按钮按了没反应 → 量 PUSH 端子对地短路时控制器有没有反应，没有就是线断了。五、验收与复盘验收我列了张清单让客户签字：每道门刷卡开门、按钮开门、断电开门（消防）、门未关报警、软件发卡/删卡，全部打勾才算完。清单一式两份，省得三个月后客户说"这个功能当时没说"，有字据对大家都好。复盘这次项目，时间分配大概是：布线 40%、接线 20%、调试排错 40%。新手往往觉得接线是技术活，其实布线阶段多花的每一分钟，都是在给调试阶段省钱。线放对了、标签打好了、每根线都用万用表确认过，调试基本就是走个流程；线放乱了，调试就是开盲盒。门禁这东西，原理真不复杂，就是四组线。但工程和 DIY 的区别，恰恰在这些"顺手"的细节里：电源留余量、强弱电分开、NO/NC 别接反、上电前先量一遍。把这些做到位，小项目基本不会翻车。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选 —— 门禁控制器要远程调试、异地管理时，内网穿透是刚需，这篇是三种方案的实测选型RustDesk 开源远程桌面：Docker 自建中继服务器，免费告别 TeamViewer —— 现场留一台旧电脑，远程桌面连回去调门禁软件，不用每次跑现场
-
从 WordPress 到 Typecho：一个小站长的博客轻量化转型记 从 WordPress 到 Typecho：一个小站长的博客轻量化转型记十年前，我在虚拟主机上一键安装了 WordPress，觉得博客这东西就该“大而全”；十年后，我把小窝搬到了 Typecho，才发现“少即是多”。这篇不讲具体哪行代码，只聊聊一个小站长的心态转变。一、我与 WordPress 的十年纠缠我的第一篇博客写于 2016 年，标题至今还留着：“Hello World！”。那时候的想法很朴素：找个免费的建站程序，写点网络技术笔记，顺便挂几张 NAS 的折腾截图。WordPress 自然是第一选择——教程最多、主题最全、插件最丰富，几乎是个“闭眼入”的答案。事实证明它也确实强大。五年里，我给小窝装过 SEO 插件、缓存插件、安全插件、表单插件、图库插件、备份插件……最多的时候装了 40 多个插件。每次打开后台，“插件有更新”的红点就像催命符一样，更新吧怕兼容性崩，不更新吧怕安全漏洞。到了 2022 年，问题开始集中爆发：后台越来越卡：打开一个页面要转半天圈，写文章常常丢失草稿；数据库膨胀：wp_options 表里各种插件残留的垃圾数据越来越多，清理一次要花一整天；安全风险高：树大招风，WordPress 的漏洞公告几乎月月有，服务器上被扫描器扫得嘶嘶作响；服务器开销大：原本 1 核 2G 的小鸡跑得好好的，加了几十个插件后 CPU 常年飘红。最要命的是，作为个人站长，我发现自己 80% 的精力都花在了“维护博客程序”上，而不是“写文章”上。这完全本末倒置了。二、轻量化思潮：我为什么开始想“换车”2023 年，我在给群晖 NAS 折腾 Docker 容器时，突然意识到一件事：我的技术栈已经全面“轻量化”了——软路由跑 OpenWrt 而不是臃肿的成品固件，图床用兰空图床而不是自己写，内网穿透用 Docker 版 FRP 而不是手动编译。唯独博客还拖着个“大块头”。于是我开始问自己一个问题：个人博客到底需要什么？能写文章、发图文教程 ✓评论功能正常 ✓访问速度快、移动端体验好 ✓后台简洁，不折腾 ✓数据掌握在自己手里 ✓WordPress 能做到这 5 点，但它附带的是 10 倍于此的冗余功能。而 Typecho，恰好就是一个“只做这 5 件事”的程序。三、搬家实战：我的迁移路线图真正动手前，我列了个清单，确保搬家不翻车。整个流程分为五步，花了大概一个周末。第一步：盘点家当先统计 WordPress 端的数据：文章数量、分类、标签、评论、媒体库文件。我发现近一半的文章是十几年前的测试残留和无意义转载——果断删掉，只带走 60 多篇真正的原创教程。这是轻量化转型的第一课：先给内容减负。第二步：导出导入Typecho 官方生态有现成的 WordPress 迁移插件（WordpressToTypecho），流程很顺：在 WordPress 后台导出 XML 数据文件；全新安装 Typecho（PHP 7.4+、MySQL，过程不到 5 分钟）；启用迁移插件，上传 XML，一键导入文章、分类、标签、评论。坑主要在媒体库：如果图片都在 wp-content/uploads 下，要手动把目录复制到 Typecho 的 usr/uploads 里，并用 SQL 或插件批量替换正文中的图片路径。我的做法是把所有图片提前迁移到兰空图床，正文统一用图床外链，反而一劳永逸。第三步：选主题这是最开心的环节。Typecho 的主题生态虽然不如 WordPress 庞大，但精品率很高。我最后选了 Joe 主题——颜值在线、功能完整、作者更新勤快，而且有现成的小程序对接方案。对个人技术博客来说，它几乎开箱即用。第四步：伪静态与细节把 WordPress 时代的链接结构尽量保留一致，避免外链 404。Typecho 在群晖 Web Station 或 Nginx 下开启伪静态都很简单，官方文档一页纸讲完。我还补了几件事：开启评论反垃圾（搭配自建 Bark 推送，评论实时到手机）；补上 sitemap，让搜索引擎重新收录；把旧站做 301 跳转到新站，权重不丢失。第五步：观察与收尾搬家后的一周我每天看日志：有没有 404、有没有评论异常、移动端排版正不正常。确认稳定后，旧 WordPress 打包成压缩包归档到 NAS，服务器资源直接省出一半。四、半年体验对比：数据说话搬家半年后，我做了一次横向对比，结论很直观：对比项WordPress 时期Typecho 时期程序体积约 50MB+，插件另算约 2MB，核心功能内置首页加载时间2.5~4 秒0.8 秒以内后台打开速度经常转圈几乎秒开安全补丁频率几乎月月有极少，攻击面小服务器占用1核2G 常年飘红同配置常年低于 20%写作体验编辑器笨重Markdown 原生，轻快最让我惊喜的是写作回归了：以前打开后台写篇文章，光等加载就消磨掉一半兴致；现在 Typecho 后台秒开，Markdown 一敲，配图一拖，发布走人。半年时间里，我的更新频率翻了一倍。五、给想转型的朋友的几句建议先断舍离，再搬家：别把十年垃圾数据原样带走，趁机精简内容，是对读者和自己都好的一件事。图床独立化：把图片从程序目录剥离出来，换任何程序都不用再为图片发愁。接受“功能少”：Typecho 没有 WordPress 那么多花哨插件，但 90% 的需求主题和少量插件就能覆盖。少折腾，就是最大的生产力。备份！备份！备份！：迁移前后各做一次完整备份（数据库+文件），NAS 上再留一份异地副本。重要的话说三遍。写在最后从 WordPress 到 Typecho，我失去的是一堆用不上的功能，得到的是一个“打开就能写”的博客。这十年建站路教会我最重要的一件事就是：工具应该服务于内容，而不是内容服务于工具。如果你也觉得自己的博客越来越重，不妨试试轻量化。少即是多，慢即是快——这句话放在博客上，一样成立。夜影小窝专注群晖 NAS、Docker、内网穿透与网络技术实战，欢迎常来坐坐。
-
-
群晖docker安装frp客户端使用星河内网穿透 使用ssh工具登录群晖（我使用的Xmanager的shell）{cloud title="Xmanager" type="default" url="https://nas.yeyhome.com:270/Xmanager%20Enterprise%205/" password=""/}拉取snowdreamtech/frpc:0.28.2版本命令：docker pull snowdreamtech/frpc:0.28.2建立启动容器添加文件选择配置的frpc.ini文件，右边保持不变/etc/frp/frpc.ini网络选择与docker host相同的网络，点击应用即可
-
群晖surveillance接入监控摄像头实现无限制空间存储录像 用nas来存储监控的录像，实现无容量空间限制的云存储也省钱了购买内存卡的费用。群晖的套件surveillance可以自定义协议接入不通品牌的摄像头。（使用的RTSP协议接入）针对群晖列表中不支持的监控用rtsp自定义协议添加路径格式在rtsp后面写入一下信息admin:监控验证码@监控内网IP地址:554/video_path配置如下（本文以海康的家用摄像头为例）各大品牌摄像头rtsp协议模版(192.168.10.199替换为自己摄像头的IP地址)海康摄像头rtsp规则(常见)rtsp://admin:admin@192.168.10.199:554/h264/ch1/main/av_streamrtsp://admin:admin@192.168.10.199:554/Streaming/Channels/101 (主码)rtsp://admin:admin@192.168.10.199:554/Streaming/Channels/102 (子码)海康摄像头rtsp规则（部分版本支持）rtsp://admin:admin@192.168.10.199:554/1rtsp://192.168.10.199:554rtsp://192.168.10.199:554/Streaming/Channels/101?transportmode=unicast&profile=Profile_1大华摄像头rtsp规则rtsp://admin:admin@192.168.10.199:554/cam/realmonitor?channel=1&subtype=0 (主码)rtsp://admin:admin@192.168.10.199:554/cam/realmonitor?channel=1&subtype=1 (子码)宇视摄像头rtsp规则rtsp://admin:admin@192.168.10.199:554/video1 (主码)rtsp://admin:admin@192.168.10.199:554/video2 (子码)rtsp://admin:admin@192.168.10.199:554/media/video1宇视硬盘录像机rtsp规则:rtsp://192.168.10.199:554/unicast/c10/s0/livertsp://admin:admin@192.168.10.199:554/unicast/c10/s0/live中威摄像机rtsp规则rtsp://admin:admin@192.168.10.199:554/Streaming/Channels/1华为摄像头rtsp规则rtsp://admin:admin@192.168.10.199:554/LiveMedia/ch1/Media2rtsp://192.168.10.199:554/stream0?username=admin&password=16位MD5TP-LINK摄像头rtsp规则rtsp://admin:a1234567@192.168.10.199:554/stream1 (主码)rtsp://admin:a1234567@192.168.10.199:554/stream2 (子码)
-
joe主题sitemap文件增加相应文章的标题显示 {message type="info" content="joe主题自带生成的sitemap.xml文件，里面只有文章的链接地址，没有包含文章的标题，感觉对搜索引擎的爬虫不太友好。"/}修改完效果，直接可以显示文章的标题便于爬虫爬取提高SEO效果打开主题\Joe\library文件下面的sitemap.php文件增加下面代码32行增加 echo "\t\t<title>" . $page['title'] . "</title>\n"; 56行增加 echo "\t\t<title>" . $article['title'] . "</title>\n";位置如下图
-
