服务器：Oracle Cloud ARM | 应用：Halo 2.x + PostgreSQL 15 + Nginx | 记录时间：2026.05.21–22

一、问题的诡异之处

我的博客（wuqishi.com）有个很邪门的毛病：每天晚上 20:00 到 23:00 准时卡，但同服务器上的其他网站屁事没有。

服务器是 Oracle Cloud 的 ARM 实例，4 核 24G 内存，跑 Docker Compose。上面除了 Halo，还有几个 Typecho 站点和纯静态页面。白天所有站点都飞快，唯独 Halo 一到晚上就跟中了邪似的——页面加载转圈、后台进不去、偶尔直接报错 ERR_CONNECTION_CLOSED​。

更离谱的是，不是一直卡，是断断续续的卡。有时候能打开，点两下又卡死；有时候彻底连不上，过几分钟又好了。这种"薛定谔的卡顿"最让人头疼，因为你根本抓不到规律。

一开始我怀疑是 Halo 2.x 基于 Java（Spring Boot）的锅，毕竟 Java 吃内存是出了名的，而 Typecho 是 PHP，随用随释放。但看了眼 Docker 配置，JVM 堆内存已经给了 5G，G1 垃圾回收器也开了，理论上不应该啊。

💡 Tip 1：遇到"选择性卡顿"，先别急着调代码或加配置。

第一步永远是确认问题范围。同服务器其他站点正常 → 排除全局资源问题；只有某个应用卡 → 问题大概率在这个应用自身、它的数据库、或者这个域名独享的流量上。

二、排查的第一步：翻日志，逐层往下挖

2.1 Nginx error.log 的异常

先看 Nginx 的 error.log​，发现大量这种报错：

2026/05/21 22:14:57 [error] 1234#1234: *45678 recv() failed (104: Connection reset by peer)
2026/05/21 22:14:57 [error] 1234#1234: *45678 upstream prematurely closed connection

而且全部指向同一个路径：

/apis/online-user.zyx2012.cn/v1alpha1/online-ws

这是我在 Halo 里装的一个"在线人数统计"插件。看起来 Nginx 把请求转发给 Halo 后，Halo 还没返回响应头就直接把连接掐断了。更可怕的是，这些报错是刷屏级别的，一秒钟能蹦出来十几条。

2.2 dmesg 里的两个关键线索

同时我看了 dmesg​，发现两个现象：

第一，Docker 容器在频繁重启。

vetha1b2c3d4: entered disabled state
vetha1b2c3d4: left promiscuous mode
docker0: port 2(vetha1b2c3d4) entered disabled state

虚拟网卡在不断销毁重建。这意味着 Halo 容器在崩溃 → 被 Docker 自动拉起 → 又崩溃的循环里。

第二，UFW 防火墙在疯狂拦截扫描。

[UFW BLOCK] IN=eth0 OUT= MAC=... SRC=185.191.171.12 DST=... DPT=5432
[UFW BLOCK] IN=eth0 OUT= MAC=... SRC=194.165.16.73 DST=... DPT=5432

满屏的 [UFW BLOCK]​，各种境外 IP 在扫我的端口：5432（PostgreSQL）、5985（WinRM）、3389（远程桌面）……

等等，5432？我的数据库端口怎么暴露在外网了？

💡 Tip 2：dmesg​ 是排查系统级问题的利器。

很多人只看应用日志，忽略了内核日志。Docker 容器频繁重启、网卡状态变化、OOM killer 杀进程，这些在 dmesg​ 里一目了然。建议用 dmesg -T | grep -E "(UFW|veth|docker0)"​ 快速过滤关键信息。

三、真凶一：数据库裸奔在公网上

我打开 docker-compose.yml​ 一看，傻眼了：

services:
  halodb:
    image: postgres:15-alpine
    ports:
      - "5432:5432"

当时为了方便用 DBeaver 连数据库，直接映射到了宿主机。但我忘了 Linux 上一个巨坑：Docker 会绕过 UFW 防火墙。

3.1 Docker 为什么能绕过 UFW？

这里有个很多人不知道的细节：

UFW 本质上是对 iptables​ 的封装，它在 INPUT​ 链里插入规则。但 Docker 在启动容器时，会在 iptables​ 的 DOCKER​ 链（属于 nat​ 表和 filter​ 表）里插入自己的规则，优先级高于 UFW 的 INPUT​ 链。

具体来说，Docker 会创建这样的 DNAT 规则：

sudo iptables -t nat -L DOCKER -n --line-numbers | grep 5432

输出：

DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:5432 to:172.18.0.2:5432

这条规则的意思是：所有访问宿主机 5432 端口的流量，都会被 DNAT 到 Docker 容器内部的 172.18.0.2:5432。它发生在 UFW 的过滤规则之前，所以 UFW 根本拦不住。

3.2 数据库日志里的暴力破解

看数据库日志更触目惊心：

2026-05-21 22:14:57.123 UTC [12345] FATAL: password authentication failed for user "postgres"
2026-05-21 22:14:57.123 UTC [12345] DETAIL: Role "postgres" does not exist.
2026-05-21 22:14:57.456 UTC [12346] FATAL: password authentication failed for user "postgres"
2026-05-21 22:14:57.789 UTC [12347] FATAL: password authentication failed for user "postgres"

黑客在用默认用户名 postgres​ 暴力破解我的数据库。因为我在 Docker Compose 里把数据库用户名改成了其他​，系统压根没有 postgres​ 这个用户，所以每次破解都是 FATAL​ 级别报错。

为什么晚上特别卡？

因为晚间是全球扫描器的高峰期（对应欧美白天工作时间），每秒几十次恶意连接。PostgreSQL 的默认配置下，每次连接都要：

1. Fork 一个后端进程（约 5-10MB 内存）

2. 进行 SSL 握手和认证计算

3. 查询系统表验证用户名

4. 失败后记录 FATAL 日志

这些垃圾请求把 CPU 和 I/O 占满了。我的 Halo 博客想查数据库？排队去吧。

3.3 修复方案

把端口绑定到本地回环：

services:
  halodb:
    image: postgres:15-alpine
    ports:
      - "127.0.0.1:5432:5432"
    environment:
      - POSTGRES_USER=halo
      - POSTGRES_PASSWORD=your_strong_password
      - POSTGRES_DB=halo

改完重启，数据库日志瞬间清净，FATAL 报错彻底消失。

💡 Tip 3：所有敏感服务的 Docker 端口映射，永远写成 127.0.0.1:PORT:PORT​。

不要偷懒只写 PORT:PORT​，那等于裸奔在公网上。UFW 在 Docker 面前就是纸老虎。如果你确实需要从外网连数据库，用 SSH 隧道或 WireGuard，而不是直接暴露端口。

四、真凶二：Nginx 反代没开长连接

数据库安静了，但网站还是偶尔卡顿。继续看日志，发现 Nginx 的 access.log​ 里有个规律：每次页面加载，除了主请求，还有一堆 /apis/...​ 的 API 请求。这些请求全部走的是：

proxy_pass http://127.0.0.1:8090;

也就是直连 Halo，没有走 upstream。

问题出在这里：我没配 upstream keepalive​。

4.1 为什么短连接会拖垮你？

Nginx 每次反向代理都新建一个 TCP 连接，用完就扔。晚上并发一高，系统里堆积成千上万个 TIME_WAIT​ 状态的连接。

你可以用 ss​ 命令验证：

ss -tan state time-wait | wc -l

我当时高峰期这个数字飙到了 8000+。

​TIME_WAIT​ 是 TCP 四次挥手的正常状态（主动关闭方等待 2MSL，确保最后的 ACK 被对方收到），但数量太多会：

• 耗尽临时端口：Linux 默认临时端口范围是 32768–60999，约 28000 个。8000+ TIME_WAIT 意味着可用端口骤减，新的请求连不上，表现为"转圈"、"白屏"。

• 占用内存：每个 TIME_WAIT​ 连接在内核里占用约 1–2KB 的 TCP 控制块，积少成多。

4.2 修复方案

在 Nginx 配置顶部定义 upstream：

upstream halo_backend {
    server 127.0.0.1:8090;
    keepalive 64;
}

然后把所有 proxy_pass http://127.0.0.1:8090​ 改成 proxy_pass http://halo_backend​，并在对应的 location 里加上：

proxy_http_version 1.1;
proxy_set_header Connection "";

这样 Nginx 和 Halo 之间保持 64 个长连接复用，再也不用频繁三次握手了。

注意两个细节：

1. ​proxy_http_version 1.1​ 是必须的，因为 HTTP/1.0 默认不支持 keepalive。

2. ​proxy_set_header Connection ""​ 是为了防止 Nginx 把客户端的 Connection: close​ 透传给后端，导致后端主动断开长连接。

改完后可以立刻用 ss​ 验证：

ss -tan state established '( dport = :8090 or sport = :8090 )' | wc -l

连接数从之前的几百个飙升到稳定的 64 个左右，而且不再增长。TIME_WAIT​ 数量也降到了正常水平（几十到一百个）。

💡 Tip 4：用 ss​ 替代 netstat​，它更快更准。

查看某个端口的连接状态分布：

ss -tan state time-wait '( dport = :8090 )' | wc -l
ss -tan state established '( dport = :8090 )' | wc -l

如果 TIME_WAIT​ 超过 5000，就要警惕了。

五、真凶三：WebSocket 插件的重连风暴

现在说回那个"在线人数统计"插件。它的原理是前端通过 WebSocket 长连接实时上报在线状态。

5.1 WebSocket 握手为什么失败？

WebSocket 不是普通的 HTTP 请求。它的建立过程是这样的：

1. 客户端发送一个带 Upgrade: websocket​ 和 Connection: Upgrade​ 头的 HTTP 请求

2. 服务器返回 101 Switching Protocols​，之后连接从 HTTP 升级为 WebSocket 全双工通道

3. 后续数据通过帧（frame）传输，不再走 HTTP 请求/响应模型

问题出在第 2 步：我的 Nginx 没正确转发 Upgrade​ 头。

Nginx 默认会把 Upgrade​ 这类非标准头过滤掉（或者当成普通 HTTP 请求处理），导致后端 Halo 收到的是一个普通的 GET 请求，而不是 WebSocket 握手请求。后端以为这只是一个普通的 API 调用，处理完就关闭了连接。

但前端 JS 检测到 WebSocket 断开，会自动重连，于是形成了"连接 → 断开 → 重连"的死循环。

5.2 日志里的套娃现场

从 access.log​ 里能清楚看到这个套娃过程：

22:14:57 "GET /apis/online-user.../online-ws HTTP/1.1" 101 197
22:14:59 "GET /apis/online-user.../online-ws HTTP/1.1" 101 169  ← 同一个 IP，2 秒后重连
22:16:04 "GET /apis/online-user.../online-ws HTTP/1.1" 101 0    ← 传输 0 字节，空连接
22:16:48 "GET /apis/online-user.../online-ws HTTP/1.1" 101 143
22:16:56 "GET /apis/online-user.../online-ws HTTP/1.1" 101 143  ← 8 秒后又重连

一个访客就能在短时间内发起 3–4 次 WebSocket 握手。晚上如果有几十个访客，加上各种爬虫，Halo 的线程池被这些无效握手占满，正常的页面请求只能排队，等到超时。

Nginx error.log​ 里的 Connection reset by peer​ 和 prematurely closed connection​ 就是这么来的——Halo 被压垮了，直接粗暴地关闭连接自保。

5.3 修复方案

我没有卸载这个插件，因为上面加了长链接后目前暂时没问题，这里做记录：可以在 Nginx 里正确支持 WebSocket。在对应的 location 里加上：

location /apis/online-user.zyx2012.cn/ {
    proxy_pass http://halo_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
}

验证：

curl -i -N   -H "Connection: Upgrade"   -H "Upgrade: websocket"   -H "Host: wuqishi.com"   -H "Origin: https://wuqishi.com"   https://wuqishi.com/apis/online-user.zyx2012.cn/v1alpha1/online-ws

返回：

HTTP/2 101 Switching Protocols
upgrade: websocket
connection: upgrade

​101 Switching Protocols​ 就说明握手成功，长连接已建立。浏览器 F12 的 Network 面板里也能看到 WebSocket 连接状态从 (pending)​ 变成 101​，之后变成绿色小圆点，不再频繁断开重连。

目前现在这个插件运行得很稳定，在线人数统计功能完全 正常，没有再出现之前的重连风暴。

💡 Tip 5：排查 WebSocket 问题时，不要只看浏览器控制台的报错。

用 curl​ 直接模拟握手请求是最快的方式。如果返回 200 OK​ 而不是 101​，说明 Nginx 或后端没正确处理 Upgrade​ 头。另外注意，HTTP/2 对 WebSocket 的支持比较特殊，Nginx 从 1.25.1 开始才支持 HTTP/2 下的 WebSocket，如果你的 Nginx 版本较老，建议用 HTTP/1.1 测试。

六、第四个隐患：恶意爬虫的骚扰

排查过程中，Nginx access.log​ 里还有一类请求让我哭笑不得：

185.191.171.12 "GET /wp-content/themes/begin/inc/go.php?url=..." 404
85.208.96.196 "GET /wp-content/themes/begin/inc/go.php?url=..." 404

SemrushBot（一个臭名昭著的 SEO 爬虫）在疯狂请求我网站上根本不存在的 WordPress 路径，我早转Typecho了，现在转到Halo了。它以为我还是是 WordPress 站点，在探测 Begin 主题的重定向漏洞（历史漏洞），想拿我的服务器当跳板做黑帽 SEO。

这些请求全部返回 404，但问题是：它们都进了 Halo 后端。

Nginx 匹配不到物理文件，就丢给 @halo_proxy​，Halo 不得不为每个 404 请求初始化一次完整的页面渲染，吐出 404 页面。一秒钟十几条，线程池又被浪费了。

6.1 处理方案

我没有在 Nginx 层面拦截这些爬虫，而是选择在 Cloudflare 处理。Cloudflare 的防火墙规则可以基于 User-Agent 直接拦截 SemrushBot、DotBot 等垃圾爬虫，不需要消耗我服务器的任何资源。

这样做的好处是：

• 垃圾流量在边缘节点就被挡掉了，根本到不了我的服务器

• 不需要维护 Nginx 里的爬虫黑名单，Cloudflare 的威胁情报库会自动更新

• 不会污染我的 Nginx 日志，access.log 里只保留真实访客

💡 Tip 6：如果用了 Cloudflare，优先在边缘节点拦截垃圾流量。

表达式代码：

(http.request.uri.path contains "/.env") or 
(http.request.uri.path contains "/.git") or 
(http.request.uri.path contains "/wp-") or 
(http.request.uri.path contains "/xmlrpc.php")

Cloudflare 的防火墙规则、Bot Fight Mode、User-Agent 拦截，都比在源站 Nginx 处理更高效。源站的资源应该留给真实用户，而不是浪费在响应爬虫上。如果你的站不是 WordPress，可以直接在 Cloudflare 里拦截所有包含 wp-content​、wp-admin​ 的请求，连 404 都不用返回。

七、其他杂项与待办

7.1 RSS 订阅的慢查询

​/rss.xml​ 每次被请求都要动态生成 115KB 的 XML，而且多个 RSS 聚合器（FreshRSS、Inoreader、AstraHub 等）每隔几分钟就来抓一次。目前暂时没做静态缓存，先放着。

💡 Tip 7：RSS 聚合器的抓取间隔各不相同。

有的 5 分钟一次，有的 30 分钟一次。你可以通过 access.log​ 分析 User-Agent，找出最频繁的聚合器，针对性地设置缓存时间。另外，Halo 的 RSS 生成是全量文章列表，如果文章很多（几百篇），每次生成都是 O(n) 的遍历，非常耗 CPU。建议考虑分页 RSS 或限制输出数量。

7.2 缩略图代理的 302 风暴

日志里发现大量这种请求：

GET /apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https://cdn.ssslove.com/...&size=m HTTP/2.0" 302 0

Halo 的缩略图服务对外链图片做了一次 302 重定向。如果页面里图片多，这一来一回多了很多无谓的请求。后续考虑直接把图片链接换成 CDN 加参数的直链，跳过 Halo 的代理层。

💡 Tip 8：Halo 的缩略图代理适合处理本地上传的图片。

如果是外链图片（比如又拍云、OSS），建议直接在前端用 CDN 的缩略图参数（如 !m​ 或 ?x-oss-process=image/resize​），跳过 Halo 的代理层，减少一次 302 跳转。

7.3 HALO_EXTERNAL_URL 的坑

Docker Compose 里 HALO_EXTERNAL_URL​ 配成了 http://localhost:8090/​，这会导致某些插件在生成回调地址、RSS 链接时用到错误的域名。

应该改成真实域名：

environment:
  - HALO_EXTERNAL_URL=https://wuqishi.com/

💡 Tip 9：HALO_EXTERNAL_URL​ 影响的不只是页面链接。

它还会影响：

• Open Graph 标签（分享到微信、Twitter 时的预览卡片）

• RSS 里的 <link>​ 和 [atom:link](atom:link)​ 元素

• 某些插件的 OAuth 回调地址

• 邮件通知里的链接

配错了会导致分享出去的文章链接是 http://localhost:8090/...​，别人根本打不开。目前我暂未修改。

八、排查思路总结：我的一套方法论

这次排查我走了一些弯路，但也验证了一套有效的方法论：

核心原则：由外到内，先拦垃圾流量，再修内部配置。

如果一开始就去调 JVM 参数、加数据库索引，可能永远找不到真凶。因为根子不在性能不足，而在资源被垃圾请求白白浪费。

九、现在的状态

改完配置、重启服务后，到今天盯着日志看了半小时：

• 数据库日志：一片安静，偶尔正常的查询交互

• Nginx error.log：零报错

• Nginx access.log：清净了很多，Cloudflare 已经挡掉了大部分垃圾爬虫

• WebSocket 插件：握手返回 101 Switching Protocols​，长连接稳定，不再频繁重连，在线人数统计功能正常工作

• 页面加载：iPad、Mac、手机 4G 测试，正常打开。

晚上 22:30 到 23:00 这段原本最卡的时间，现在流畅得跟白天一样。（今晚继续再看看）

十、反思：六个容易被忽视的坑

坑 1：Docker 端口映射默认暴露公网，UFW 拦不住

数据库、Redis、MQ 这类敏感服务一定要绑 127.0.0.1​。别信 UFW，信 iptables -t nat -L DOCKER​。

坑 2：Nginx 反代理默认是短连接

高并发场景必须开 keepalive​，否则 TIME_WAIT​ 会拖垮你。ss -tan state time-wait | wc -l​ 超过 5000 就要警惕了。

坑 3：WebSocket 不是"配了就行"

​Upgrade​ 和 Connection​ 头缺一不可。可以用 curl​ 模拟握手快速验证，返回 101​ 才算成功。另外注意 Nginx 版本，HTTP/2 下的 WebSocket 需要 Nginx ≥ 1.25.1。

坑 4：第三方插件要审慎，但也不必一刀切

这次在线人数插件的问题根源不在插件本身，而在 Nginx 配置缺失。修复后插件运行得很稳定，功能完全正常。所以遇到插件相关的问题，先排查基础设施（Nginx、反向代理、防火墙），不要急着卸载。

坑 5：日志是最好的 debugger

这次排查全程没改一行 Java 代码，所有问题都是从日志里抠出来的。养成看日志的习惯，比盲目调参重要得多。

建议给 Nginx 日志加上这两个字段，一眼就能看出是前端慢还是后端慢：

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" '
                'rt=$request_time urt=$upstream_response_time';

• ​rt​（request_time）：客户端视角的总耗时

• ​urt​（upstream_response_time）：后端处理耗时

如果 rt​ 很大但 urt​ 很小 → 问题在网络或 Nginx；如果 urt​ 很大 → 问题在后端。

坑 6：不要忽视爬虫的影响

SemrushBot、DotBot 这些商业爬虫非常 aggressive，它们不会遵守你的 robots.txt​，而且专门挑 WordPress 漏洞路径扫。如果你的站不是 WP，在 Cloudflare 或 Nginx 层直接拦截，别浪费后端资源。

如果你也在用 Halo 或者类似的 Java 博客系统遇到晚间卡顿，希望这篇记录能给你一些排查思路。有时候问题不在代码多复杂，而在某个配置细节、某个插件、或者某个暴露在公网上的端口。

最后吐槽一句：SemrushBot 是真的执着，从 21:00 到 23:00 不间断地扫了整整两个小时，被 Cloudflare 挡了上百次还在试。这种敬业精神，用在正道上早成架构师了。

写于 2026 年 5 月 22 日凌晨，部分内容资料由AI查询后进行整理而成。

前言

最近发现了一个让我眼前一亮的项目——awesome-gpt-image-2，它不是又一个 AI 绘画工具，而是一套完整的 GPT-Image2 提示词工程体系。用了两周后，我来和大家分享我的真实体验。

📌 一句话总结这是什么

awesome-gpt-image-2 是一个开源的 GPT-Image2 提示词模板库和工业级引擎，收录了 450 个真实逆向工程案例 和 20+ 个可复用的提示词模板，覆盖 UI 设计、信息图、海报、电商、品牌等 13 大场景。

🔍 为什么需要这个工具？

说实话，一些 Midjourney、Stable Diffusion、DALL-E 3 等主流 AI 绘画工具，但总遇到这些问题：

❌ 传统方式的痛点

✅ 这个项目的解决思路

​awesome-gpt-image-2​ 的核心理念是 "Prompt-as-Code"（提示词即代码）——把散乱的文字描述变成结构化的、可版本控制的、可自动执行的"协议"。

这让我想到：如果把 AI 提示词当成代码来管理，是不是就能解决上述所有问题？

🎯 核心功能：它到底能做什么？

经过实际使用，我发现这个项目的价值主要体现在三个方面：

1️⃣ 450 个真实案例库 — 不是 PPT 截图，是实战经验

这是我第一次见到这么大规模的、经过验证的真实案例集合。每个案例都包含：

• ✅ 原始提示词（完整可复制）

• ✅ 生成的效果图

• ✅ 所属分类和标签

• ✅ 适用的模板类型

覆盖范围

案例覆盖的 13 大分类、19种风格、10个场景：

案例分类画册

我的使用感受： 浏览这些案例时，我能明显感觉到它们不是"理想化的 Demo"，而是真实的社区作品，有些甚至能看到明显的改进空间——这种真实性反而让我更信任。

2️⃣ 20+ 工业级模板系统 — 从"灵感"到"生产线"

这是我最喜欢的部分。项目提供了 结构化的模板框架，每个模板都包含：

📋 模板标准结构（以"场景叙事"为例）

模板：场景叙事
用途：用于分镜、世界观、直播场景和情绪叙事画面。
视觉方向：场景与叙事 / 场景 / 插画 / 叙事 / 社媒 / 分镜

请基于以下结构生成一条可直接用于 GPT Image 2 的图片 Prompt：
- 主体：[要生成的产品、人物、空间、界面或信息主题]
- 场景：[使用环境、叙事背景、受众语境]
- 构图：[画面比例、镜头距离、主体位置、层级关系]
- 风格：[材质、光线、色彩、时代感、品牌气质]
- 文本：[必须准确显示的标题、标签、按钮或说明文字]
- 细节：[关键装饰、辅助元素、信息标注、交互层]
- 输出：[清晰度、比例、完成度、可读性要求]

核心约束：
- 定义人物、地点、时间、冲突、情绪和机位。
- 让场景细节服务故事。

需要避免：
- 避免通用幻想背景。
- 让故事线索在画面里可见。

​核心价值：

• 🔧 原子化拆解 — 把复杂需求分解为：主体 + 场景 + 构图 + 风格 + 文本 + 细节 +输出

• 🎯 防坑指南 — 每个模板都明确告诉你核心约束和需要避免

• 🔄 可组合性 — 不同模板的参数可以灵活搭配

3️⃣ Agent 技能集成 — 让 AI 自己选模板

这个功能对开发者特别友好。项目提供了一个 gpt-image-2-style-library 技能，可以集成到 Claude Code​、OpenAI Codex​、Cursor​ 等 AI 编程助手中。

安装命令（一行搞定）：

npx skills add freestylefly/awesome-gpt-image-2 --skill gpt-image-2-style-library --agent claude-code codex --global --yes --copy

使用示例：

用户: 使用样式库技能生成一张关于"2025年AI发展趋势"的信息图
Agent: [自动调用技能]
      → 匹配到 infographic-engine 模板
      → 选择科技风格标签
      → 输出结构化提示词（包含模块定义、配色方案、布局约束）

🎓 适用人群分析

✅ 强烈推荐给这些人

1. 内容创作者 / 博主 — 需要大量配图且追求效率

2. 电商运营 / 设计师 — 批量生成商品图、活动海报

3. 产品经理 / UX 设计师 - 快速出原型图、界面概念图

4. AI 应用开发者 - 将提示词工程集成到自己的产品中

5. 独立开发者 / 创业者 - 降低设计成本，一人兼任设计和开发

⚠️ 可能不太适合

1. 纯艺术创作追求者 - 这里的模板偏商业化，不够"艺术"

2. 只用 Midjourney 的用户 - 模板语法可能需要适配

3. 完全不想学新技术的小白 - 还是有一定上手门槛的

📊 与其他免费方案对比

结论： 如果你需要系统性、可复制、可自动化的提示词方案，awesome-gpt-image-2 是目前最专业的选择。如果你只是想找灵感，PromptHero 或 Civitai 可能更方便。

🛠️ 安装与快速开始

方式一：在线浏览（零门槛）

直接访问：https://gpt-image2.canghe.ai/

无需注册即可浏览所有案例，登录 Google 账号后可以测试生成。

方式二：克隆仓库（推荐开发者）

git clone https://github.com/freestylefly/awesome-gpt-image-2.git
cd awesome-gpt-image-2

# 查看案例
打开 docs/gallery.md

# 查看模板
打开 docs/templates.md

方式三：安装 Agent 技能（推荐重度使用者）

# 安装到全局（所有 Agent 都可用）
npx skills add freestylefly/awesome-gpt-image-2 --global --all --copy

# 重启你的 AI 助手（Claude Code / Cursor / Codex）
# 然后就可以使用了！

💡 我的个人使用技巧

经过两周的深度使用，我总结了几个使用技巧：

技巧 1：先找案例，再套模板

不要直接背模板参数！正确流程是：

1. 在在线网站上按分类、风格、场景筛选

2. 找到 2-3 个和你需求接近的案例

3. 看它们用的是哪个案例

4. 复制该模板的结构，只替换内容

这样成功率提高 70%+

技巧 2：善用"负面约束"

每个模板的 Pitfalls 部分其实是宝藏。我会把这些"不要做"的事情显式写到提示词里：

- 不要出现人物手指
- 避免文字重叠
- 禁止渐变背景（保持纯色）

显式约束比隐式期望有效得多

技巧 3：建立个人模板库

在项目的基础上，可以建立了自己的 "常用模板速查表"：

# Top 5 模板

1. infographic-engine     → 技术文章配图（80% 使用率）
2. ui-screenshot-system  → 教程截图模拟
3. poster-layout-system  → 公众号封面
4. product-commerce-visual → 电商合作项目
5. brand-touchpoint-board → 品牌提案

把通用模板个性化，效率翻倍

📈 项目活跃度与发展前景

当前状态（截至 2026 年 5 月）

• ⭐ GitHub Stars：持续增长中（社区活跃）

• 📦 最新案例：Case #450（仍在更新）

• 🌐 在线网站：正常运行，支持实时生成测试

最后的话

awesome-gpt-image-2 不是那种"惊艳一时"的工具，而是越用越好用的基础设施。

希望这类开源项目越来越多也越来越好，让AI成为全民可用的工具。

哦，对了，这篇文章的头图就是使用了这个项目的技能做的哦~٩(ˊᗜˋ*)و

相关链接：

🌐 在线体验：

📦 GitHub 仓库：

📖 完整案例集：

🤖 Agent 技能文档:：

写在前面

最近想给家里的群晖找点新活儿干，正好刷到 xcq0607/lxserver​ 这个项目。简单说，它就是在群晖上搭一个音乐服务端，然后你打开浏览器就能听歌——不用装任何 App，手机、电脑、平板都能用。歌单数据存在 NAS 本地，换设备也不怕丢。

这个项目是 LX Music 的增强版服务端。原版 lyswhut/lx-music-sync-server​ 只是个纯同步后端，没界面，配置也麻烦。而这个增强版在内置同步功能的基础上，加了一个完整的 Web 播放器。所以你可以把它当同步后端用，也可以直接当主力播放器用。

我的环境是群晖 DS918+，DSM 7.3.2，下面一步步记录部署过程，尽量详细到小白也能跟着做。

准备工作

确认群晖环境

打开群晖的「控制面板」→「信息中心」，确认 DSM 版本。本文基于 DSM 7.3.2，其他 7.x 版本应该也差不多。

安装 Container Manager

打开「套件中心」，搜索「Container Manager」并安装。这是群晖官方的 Docker 管理工具，DSM 7.2 之后取代了旧版的 Docker 套件。

开启 SSH（推荐）

后面部分操作需要命令行，建议先开启 SSH。进「控制面板」→「终端机和 SNMP」→「终端机」，勾选「启用 SSH 功能」，端口默认 22。

创建存放目录

打开「File Station」，在 docker​ 共享文件夹下创建目录结构：

docker/
└── lx-music/
    ├── data/
    ├── logs/
    └── cache/

操作步骤：

1. 右键 docker​ 文件夹 →「新建文件夹」→ 输入 lx-music​

2. 进入 lx-music​，再新建三个子文件夹：data​、logs​、cache​

这三个目录分别用来存用户数据、运行日志和缓存文件。通过卷映射挂到容器里，这样即使容器删掉重建，数据也不会丢。

docker-compose.yml 内容

不管你用下面哪种部署方式，这个配置文件的内容是一样的。先准备好：

version: "3.8"

services:
  lx-music-server:
    image: xcq0607/lxserver:latest
    container_name: lx-music-server
    restart: unless-stopped
    ports:
      - "9527:9527"
    volumes:
      - ./data:/server/data
      - ./logs:/server/logs
      - ./cache:/server/cache
    environment:
      - NODE_ENV=production
      - FRONTEND_PASSWORD=你的管理后台密码
      - ENABLE_WEBPLAYER_AUTH=true
      - WEBPLAYER_PASSWORD=你的播放器密码

参数说明：

⚠️ 密码一定要改！ FRONTEND_PASSWORD​ 和 WEBPLAYER_PASSWORD​ 建议设成不一样的。前者是进管理后台用的，后者是打开播放器页面用的。如果打算暴露到公网，密码设复杂一点。

部署方式一：Container Manager 的「项目」功能（推荐新手）

DSM 7.2 之后，Container Manager 新增了「项目」功能，支持图形界面管理 Docker Compose，对新手最友好。

部署方式二：SSH 命令行 + Docker Compose

适合习惯用命令行的用户，操作效率高，以后修改配置也方便。

cd /volume1/docker/lx-music

docker-compose up -d

[+] Running 2/2
 ✔ Network lx-music_default  Created
 ✔ Container lx-music-server  Started

docker logs -f lx-music-server

部署方式三：Container Manager 手动创建容器

如果你不想用 Compose，也可以手动一步步创建容器。这种方式配置分散，以后修改不太方便，但适合想深入了解每个参数的用户。

Web 播放器使用指南

Web 播放器有以下核心特性：

现代化界面

采用清爽的现代化 UI 设计，支持深色模式。播放页是左右分栏设计，左侧专辑封面（带毛玻璃沉浸效果），右侧歌词区。当前唱到的歌词会用高亮色标注。

多源搜索

支持聚合搜索各大音乐平台的资源。搜索框右上角可以切换音源平台（网易云、QQ音乐、酷狗、酷我、咪咕）。默认显示「热门搜索」，跟各平台的热搜榜同步。

内容与播放列表

支持多平台歌单的浏览、搜索与一键播放。歌单详情面板包含封面、作者、简介等完整信息。播放队列支持拖拽排序、批量管理及快速定位当前播放。

首次打开

浏览器访问 http://群晖IP:9527，输入 WEBPLAYER_PASSWORD​ 设置的密码。

底部控制条的功能包括：

• 播放/暂停、上一首/下一首

• 播放模式：顺序播放、随机播放、单曲循环

• 倍速播放

• 音量调节

• 下载按钮（可以下载当前播放的歌曲）

• 歌词按钮（显示/隐藏歌词）

• 评论按钮（查看歌曲评论）

• 播放队列按钮（打开当前播放列表）

歌单浏览

点左侧「歌单」，能看到各平台推荐的歌单，带封面、标题、作者、播放量。点进去可以查看歌单详情，包含完整歌曲列表，一键播放全部。

播放队列管理

点击底部控制条右侧的列表图标，打开播放队列。支持拖拽排序、批量删除、快速定位当前播放歌曲。

深色模式

播放器支持深色模式，在设置里可以切换。

音源配置：不配置就搜不到歌

这是最关键的一步，很多人部署完发现搜不到歌，就是这里没弄。

这个项目本身不带音源，需要手动导入第三方音源脚本。根据项目文档，音源导入在管理后台的「系统配置」→「自定义源管理」里操作。

获取音源

音源是 .js​ 格式的脚本文件，通常由社区维护。获取渠道：

• GitHub 上搜索 lx-music-source​ 相关仓库

• 各种 NAS 交流群、技术论坛

导入音源

进管理后台 →「系统配置」→「自定义源管理」，有两种导入方式：

方式一：上传本地文件

1. 点击「上传脚本文件」

2. 选择你下载好的 .js​ 音源文件

3. 上传完成

方式二：从 URL 导入

1. 点击「从 URL 导入」

2. 输入音源脚本的远程地址

3. 点「开始导入」

导入成功后，列表里会显示音源信息：名称、作者、大小、版本号，以及支持的平台标签（比如「网易」「QQ」「酷狗」「酷我」「咪咕」）。

启用音源

重点：导入后默认是「已禁用」状态！

必须点击状态按钮，把它改成「已启用」。很多人部署完搜不到歌，就是因为漏了这一步。

启用后，回到播放器页面，搜索功能就正常了。

音源备份

这是我常用的音源，是其他网友分享的，大家需要就自取：

• 百度网盘：https://pan.baidu.com/s/1vsRmTWIEuVDJrzWsPVFxUA?pwd=2mmd

• UC 网盘：https://drive.uc.cn/s/23ceaa898d9a4?public=1

音源脚本由第三方维护，可能会失效。如果某天搜不到歌，大概率是音源挂了，需要换新的。

歌单同步：打通桌面端和移动端

这个项目本质上是 LX Music 的同步服务端。如果你已经在用 LX Music 桌面版或移动版，可以把这个服务端作为同步后端，实现多设备歌单统一。

桌面端设置

1. 打开 LX Music 桌面版

2. 进「设置」→「同步」

3. 开启「启用同步」

4. 同步服务地址填 http://群晖IP:9527​

5. 用户名和密码填管理后台里创建的用户

6. 点击「连接测试」，成功后会自动同步

移动端设置

1. 打开 LX Music 移动版

2. 进「设置」→「同步」

3. 同样填群晖地址和用户名密码

4. 连接成功后数据自动同步

网页端同步

网页播放器本身也支持登录。用同步用户登录后，收藏的歌单会存在群晖的 data​ 目录里。你在电脑浏览器上收藏的歌，手机浏览器打开同一个地址登录后也能看到。

常见问题排查

1. 容器启动失败，日志报端口冲突

现象：docker-compose up -d​ 后容器起不来，日志里有 bind: address already in use​

原因：群晖上 9527 端口被其他服务占用了。

解决：修改 docker-compose.yml​ 里的端口映射，把左边的本地端口改成别的，比如 19527​：

ports:
  - "19527:9527"

然后访问 http://群晖IP:19527​。

2. 卷映射报权限错误

现象：容器日志里出现 EACCES: permission denied​

原因：群晖共享文件夹权限不足，容器无法读写映射的目录。

解决：

1. 打开「File Station」

2. 右键 docker/lx-music​ 文件夹 →「属性」→「权限」

3. 点击「新增」，用户选 Everyone​，勾选「读取」和「写入」

4. 勾选「应用到这个文件夹、子文件夹和文件」

5. 保存后重启容器

3. 搜不到歌

现象：播放器里搜索没有任何结果

排查步骤：

1. 确认音源已导入（后台 → 系统配置 → 自定义源管理）

2. 确认音源状态是「已启用」，不是「已禁用」

3. 确认当前选择的音源平台支持你要搜的歌

4. 如果以上都没问题，可能是音源脚本失效了，需要换源

4. 外网访问不了

现象：内网能打开，外网用域名或公网 IP 访问不了

排查步骤：

1. 确认路由器做了端口转发，把外部端口映射到群晖的 9527

2. 确认群晖防火墙放行了这个端口（控制面板 → 安全性 → 防火墙）

3. 如果用了反向代理，检查代理规则是否正确

5. 密码忘了怎么办

如果忘了管理后台密码，直接修改 docker-compose.yml​ 里的 FRONTEND_PASSWORD​，然后重启容器：

cd /volume1/docker/lx-music
docker-compose down
docker-compose up -d

外网访问与 HTTPS（进阶）

如果只想在内网用，上面的配置已经够用了。但如果想在外面也能听歌，建议做以下配置。

方案一：端口转发（简单但不安全）

在路由器里做端口转发，把外网的某个端口（比如 9527）映射到群晖内网的 9527。然后外网用 http://公网IP:9527​ 访问。

缺点：HTTP 明文传输，密码容易被截获。只适合临时用用。

方案二：群晖反向代理 + HTTPS（推荐）

群晖自带反向代理和 Let's Encrypt 证书，配置如下：

1. 进「控制面板」→「登录门户」→「高级」→「反向代理服务器」

2. 点击「新增」

3. 来源设置：

   • 协议：HTTPS

   • 主机名：music.yourdomain.com​（你自己的域名）

   • 端口：443​（443被封换其他的）

4. 目的地设置：

   • 协议：HTTP

   • 主机名：localhost​

   • 端口：9527​

5. 保存

然后去「控制面板」→「安全性」→「证书」，申请 Let's Encrypt 证书，绑定到 music.yourdomain.com​。

配置完成后，外网用 https://music.yourdomain.com:端口号​ 访问，安全且方便。

日常维护

更新镜像

作者可能会发布新版本，更新方法：

cd /volume1/docker/lx-music
docker-compose pull
docker-compose up -d

数据存在卷映射的目录里，更新不会丢失。

备份数据

定期把 /docker/lx-music/data/​ 目录备份一下，里面存着用户数据和歌单。可以用群晖的「Hyper Backup」套件自动备份到另一块硬盘或者云端。

查看资源占用

进 Container Manager →「容器」→ 选中 lx-music-server​，可以看到 CPU 和内存占用。根据项目文档，这个服务资源占用很低。

写在最后

这个项目对 NAS 用户来说挺实用的，部署简单，资源占用低，关键是打通了多设备的听歌体验。不用在手机上装一堆音乐 App，打开浏览器就能搞定。

适合人群：

• 有群晖或其他 NAS，愿意折腾的

• 不想装太多 App，喜欢网页端轻量体验的

• 希望歌单数据自己掌控，不依赖第三方平台的

不适合：

• 追求极致无损音质的发烧友（网页播放器的音质取决于音源质量）

• 完全不想动手配置的懒人

如果部署过程中遇到问题，可以先对照上面的「常见问题排查」部分自查。还是搞不定的话，建议去项目 GitHub 的 Issues 区看看。

相关链接

本项目地址：

桌面客户端：

移动客户端：

一、事情是这样的

公司突然通知：“要考安全生产，题库发群里了，大家自己看。”

打开那个Word文档，我沉默了。

500道题，密密麻麻挤在一起。没有分类，没有标签，翻几页就忘了前面看过什么。错题得自己拿本子记，学到哪了全凭感觉。

我试着看了半小时，眼睛酸，脑子乱，完全不知道看了多少、还剩多少。

"这不行，得想个办法。"——我的第一反应不是"硬看"，而是"能不能做个工具？"

于是接下来几个周末，我折腾出了这个学习平台。

二、我遇到了哪些问题

问题1：记住答案位置，而不是知识点

按顺序做题，做着做着发现：我不是真会，只是记住了"这题选C"。

我的解法：每次打开，题目顺序随机；同一道题，选项顺序也随机。

// 题目顺序打乱
const questionOrder = Utils.shuffleArray([...Array(totalQuestions).keys()]);

// 选项顺序打乱，正确答案位置跟着变
const shuffledOptions = Utils.shuffleArray([...originalOptions]);
const shuffledAnswer = shuffledOptions.indexOf(originalAnswer);

这样一来，同一道题每次出现都不一样。你不能靠记位置，只能真懂。

问题2：进度总丢

Word文档没有记忆功能。今天看到第50题，明天打开，得从头翻。

我的解法：自动保存学习进度，下次打开接着来。

// 存到本地
studySession: {
    questionIds: [],      // 题目列表
    currentIndex: 0,      // 做到哪题了
    answeredIds: [],      // 哪些题已经答过
    questionStates: {}    // 每道题的答题状态
}

关掉浏览器、重启电脑，回来还能继续。不用翻，不用找，打开就是上次离开的地方。

问题3：上一题下一题，跳来跳去

点"上一题"回去看看，再点"下一题"，结果跳到一道全新的题。刚才那道去哪了？

我的解法：用数组记录浏览历史，像浏览器的前进后退。

图片生成词：简洁的流程图，显示浏览历史栈的工作原理，箭头指示前进后退，清晰的步骤标注，蓝色和白色主调，技术文档风格

浏览记录：[第1题, 第5题, 第3题]
                    ↑
                  当前在这里

点"上一题" → 回到第5题
点"下一题" → 回到第3题（不是新题！）

只有回到最末尾，点"下一题"才会出新题

这样导航就顺了。想回顾就回顾，回顾完继续往前走。

问题4：手机上看太难受

用手机做题，各种按钮、进度条占满屏幕，题目被挤到只剩一点点。

我的解法：压缩顶部空间，把进度直接放在题号后面。

之前：

• 第一行：题型、分类、题号

• 第二行：筛选控件

• 第三行：进度条 + 百分比

现在：

• 第一行：题型、分类、第9/58题 (14%)、筛选控件

• 没了

答题区域一下子大了不少。手机上按钮也改成垂直排列，不容易点错。

三、技术方面的一些事

纯前端，零后端

整个项目：

• 一个HTML文件

• 几个JS文件

• 没有服务器

• 没有数据库

• 数据存在浏览器本地

部署超简单，丢到GitHub Pages就行。

模块化

js/
├── app.js          // 页面切换、初始化
├── study.js        // 学习逻辑（最复杂）
├── exam.js         // 考试模块
├── state.js        // 状态管理
├── storage.js      // 本地存储
├── ui.js           // 界面控制
└── utils.js        // 工具函数

每个文件干一件事，改起来不头疼。

AI帮了大忙

说实话，没有AI辅助，我不可能在几个周末做完。

• 写代码：复杂逻辑先让AI生成骨架，我再改

• 找Bug：出错直接把代码和报错给AI，省得自己瞪眼看

• 查文档：不用翻MDN，直接问AI

AI不是替代我，是让我更快。就像用计算器，你还是得知道怎么算。

四、功能清单

学习计划

• 分三个阶段：基础→强化→冲刺

• 完成一阶段才能解锁下一阶段

• 记录连续学习天数

题库学习

• 500+题，覆盖法律、法规、国标

• 题目随机出现

• 选项随机排列

• 按类别、题型筛选

• 自动保存进度

• 上一题/下一题导航

习题本

• 错题自动收集

• 收藏夹

• 错题重做

• 批量清空

模拟考试

• 60分钟限时

• 60道题

• 100分制，60分及格

• 考完自动算分

• 错题自动进习题本

体验优化

• 手机、平板、电脑都能用

• 提示消息从中间上方弹出，不挡题目

• 答题区域尽量大

五、踩过的坑

坑1：新学习继承了旧状态

现象：点开始新学习，第一题直接显示答案。

原因：questionStates​没清空，上次学习的答题状态还在。

修复：初始化新会话时，questionStates​必须设为空对象。

AppState.studySession = {
    // ...其他字段
    questionStates: {}  // 从这里开始，别继承旧的
};

坑2：最后一题进度不满

现象：500题全做完了，进度显示99%。

原因：更新进度的函数在记录答案之前执行了。

修复：调整执行顺序，先记录答案，再更新进度。

坑3：随机到重复题目

现象：同一道题连续出现好几次。

原因：纯随机，没有排除已答题。

修复：只从未答题里随机。

const unanswered = allQuestions.filter(q => !answeredIds.includes(q.id));
return unanswered[Math.floor(Math.random() * unanswered.length)];

六、亮点：答案解析和记忆技巧

本身题目只有题干和答案，这多不方便记忆啊，于是我用kimi，花了好长时间调试，然后给每道题都加了答案解析和记忆技巧。

答案解析：题目出自哪条安全生产的法律法规，做到有法可依。

记忆技巧：有个口诀（顺口溜），帮助记忆。

​七、还有什么想做

• 成就系统（连续学习7天勋章之类的）

• 学习数据统计（哪类题错得多）

• 支持导入Excel题库

• 同事间排行榜

• 离线使用（PWA）

先这样吧，考过的话，就考过了...

八、最后说两句

做这个工具，我最大的感受是：

AI真的能提高效率。 几个周末做完一个完整应用，以前不敢想。但AI只是工具，关键还是得有想法、知道要解决什么问题。

用户体验比技术重要。 从Word到网页，技术上没什么难的，但体验差太多了。题目随机、进度保存、手机适配，这些才是让人愿意用的原因。

简单最好。 纯前端、无后端、零依赖，部署和维护都省心。

相关链接

• 项目源码：

  https://github.com/NoEggEgg/learning_platform_xinsen

• 在线试用：

  https://noeggegg.github.io/learning_platform_xinsen/

那一刻，风停了

这两天在看漫剧《你凭什么认为我会一直喜欢你呢》，蛮有感触的。

里面有一个镜头始终挥之不去：

男主在追求了女主长达7年，第二次表白时，等来的依然是对方毫不留情的拒绝。享受着男主的好，给不了回应却又舍不得男主。

那一刻，男主没有声嘶力竭的争吵，也没有一蹶不振地沉沦，他只是—不爱了。

剧中男主说过一句话，印象深刻：

不平等的不是爱情，是一方的得寸进尺和另一方的自我感动。

很多人在这部剧中看到了自己的影子。我们曾像信徒一样守着一份不对等的感情，以为只要自己做得再多一点，就能让荒原长出玫瑰。可到头来才发现，在这个世界上，最难叫醒的不是装睡的人，而是那个沉溺于牺牲、不肯放过自己的自己。

于是，这句反问——“你凭什么认为我会一直喜欢你呢？”——不再只是一句台词，它更像是一个在悬崖边及时止步的人，对自己人生的深情告白。

一、 所谓的深情，若无回响，便只是路过的风

杨绛先生曾说：“人间不会有单纯的快乐，快乐总带着烦恼。”在爱情里，这份烦恼往往源于“期待的错位”。

那些看似不求回报的付出，内核里其实都藏着一颗渴望被看见、被珍视的心。当一方习惯了索取，爱就变成了一场单向的布施。在剧中，男主每一次的“不求回报”地好，都像是在往一个漏风的口袋里装金子，口袋永远装不满，而他却渐渐千疮百孔。他以为那些深情与付出，但在对方眼里，那不过是廉价的、不需要支付成本的便利。

即使后来她醒悟了，知道珍惜了，可是，已经晚了。

好的关系，是当他在风雨中为你撑伞时，你也会下意识地往他的方向靠拢。

所有的深情，都需要一个温暖的落脚点。如果不被回应，那付出就变成了一场自虐式的透支。

我们要懂得，那个愿意为你弯腰系鞋带的人，也同样期待着你在过马路时，能紧紧回握他的手。

二、 在这场不可控的冒险里，做彼此的“安全绳”

三毛曾写道：“爱如果不落到穿衣、吃饭、睡觉、数钱这些实实在在的生活中去，是不容易长久的。”

既然爱情是一场不可控的意外冒险，充满了个性的磨合与生活的琐碎，那我们就不能只靠满腔孤勇。双向奔赴，其实就是给这场冒险拴上一根“安全绳”。

所谓双向，不是你给我买一件礼物，我回你一份红包，而是在漫长的岁月里，双方都有那种“唯恐对方受委屈”的觉悟。如果只有一个人在拼命拉绳子，绳子迟早会断，甚至会勒伤那个最用力的人。

只有双方都用力，才能在翻山越岭时感受到对方的存在。这种坚定，是在我最疲惫、想要放弃整个世界的时候，知道回头就能撞进你的怀里；是在你最迷茫、怀疑自我价值的时候，我愿意收起我的羽翼，在每一个平凡的清晨为你递上一杯温热的咖啡。

三、 最好的姿态，是两个灵魂的并肩同行

舒婷在《致橡树》里写下了关于爱情最美的姿态：“我必须是你近旁的一株木棉，作为树的形象和你站在一起。”

这便是最高级的双向奔赴——我们不是在泥潭里互相拉扯、彼此消耗，而是彼此为了双方在一起而共同努力。

不要怕在这场冒险中遇到错的人，因为最美的风景往往不在于终点，而在于那个“因为爱而变得更好”的过程。

• 不用求，而是相扶： 当你不用为了讨好而小心翼翼，而是双方都为了对方而互相帮助，为了在一起而共同努力。

• 相互照亮： 最好的爱，是两个本就完整的人，决定一起去看一看这世间更远的风景。你优秀，我也不差；你珍惜，我便加倍。

这种并肩，让原本不可控的冒险，多了一份“万事有你”的笃定。

【结语：愿每一份赤诚，都有回响】

“你凭什么认为我会一直喜欢你呢？”

这句台词其实是一声警钟，它提醒我们要时刻审视手中的爱。爱情这场冒险，最美妙的瞬间不是最初的心动，而是历经风霜后，发现对方依然站在触手可及的地方。

别让那个爱你的人，在你的冷漠中攒够失望；也别让那个不爱你的人，在你的卑微中肆意妄为。

我们要有爱人的赤诚，去体验那份心动；但我们更要有不爱的自由，当温情变成了单方面的消耗，我们要有勇气拍拍身上的灰尘，头也不回地走向下一个黎明。

愿每一场爱，都是一场坚定的双向奔赴；愿每一份赤诚，都能在另一个人的心房里，听到最温柔的回响。愿我们在这场冒险的终点，看见的不仅是爱人，更是那个闪闪发光的、更棒的自己。

我之前分享过一个书签脚本：

随着最近接触 Halo 2.x 等现代博客系统越来越多，我发现这个老脚本"失灵"了。问题根源不再是简单的"找不到输入框"，而是前端框架的响应式绑定机制——你改了 value​，框架并不知道，点击提交时数据就被重置了。

为了解决这个问题，在跟AI死磕良久，对代码进行了数次重构与逻辑审计之后，最终打磨出了这套全平台通用版。

走过路过，瞧一瞧看一看了嘿~

一、 探究一下为什么评论填充脚本为何失灵

以前的填充脚本在 Typecho 上表现完美，但在 Halo 2.x 或一些现代 Vue/React 主题上，填完后点击提交，信息会瞬间消失，或者啥也没填充上。

这并不是因为找不到元素，而是"数据绑定"断了。 现代前端框架（如 Vue 3、React）不再通过读取 DOM 的 value​ 来获取数据，而是通过监听 input​ 事件来同步内部状态 。如果你的脚本只是修改了 value​ 而没有触发相应的事件，框架的内部变量依然是空的，提交时自然会"穿帮"。

Vue 的 v-model​ 指令本质上是 :value​ 绑定与 @input​ 事件监听器的语法糖 。当用户输入时，input​ 事件被触发，框架将 event.target.value​ 同步到内部状态；反之，当状态变化时，框架更新 DOM 的 value​。但​如果通过脚本直接修改 value​ 而不派发事件，框架的监听器永远不会被触发​，导致状态与 DOM 脱节。

各平台架构差异对比

二、 完整代码（详细注释版）

代码中不仅考虑了选择器的覆盖，更核心的是解决了数据同步和异步渲染的问题。

核心点

1. ​事件驱动同步​：通过触发 input​、change​、blur​ 三重事件，确保 Vue/React 等框架的响应式系统能够捕获到数据变化 。

2. ​MutationObserver 异步捕获​：针对评论框异步注入的场景（如 Valine、Waline），监听 DOM 变化并在元素出现时自动填充。

3. ​Shadow DOM 穿透​：递归遍历 shadowRoot​，兼容基于 Web Components 的第三方评论系统。

4. ​隐藏域规避​：过滤 type="hidden"​ 的输入框，避免误触反垃圾"蜜罐"机制。

5. ​单次执行去重​：依赖执行周期内的状态判断，避免对同一元素重复填充。

源代码

/*
 * 全平台评论自动填充脚本 (通用增强版 V2.0)
 * 核心：响应式事件同步 + MutationObserver 异步捕获 + 隐藏域规避
 */
(function() {
  // --- [1] 个人信息配置区 ---
  var config = {
    data: {
      n: '吴蛋蛋',              // 你的昵称
      e: 'me@wuqishi.com',      // 你的邮箱
      w: 'https://wuqishi.com'  // 你的网址（末尾不要留空格）
    },
    // --- [2] 属性选择器规则库 ---
    // 涵盖 Typecho, Halo, WP, Z-Blog 等主流主题特征
    rules: {
      n: ['#author', '#inpName', 'input[name="author"]', 'input[placeholder*="昵称"]'],
      e: ['#mail', '#email', 'input[name="email"]', 'input[placeholder*="邮箱"]'],
      w: ['input[type="url"]', '#url', 'input[name="url"]', 'input[placeholder*="网址"]']
    }
  };

  var filledCount = 0;
  var observer = null;

  /**
   * 执行填充逻辑
   * 返回 boolean：是否成功填充至少一个字段
   */
  function executeFill() {
    var foundThisRound = 0;
    for (var k in config.rules) {
      var selectors = config.rules[k];
      for (var i = 0; i < selectors.length; i++) {
        var el = deepQuery(document, selectors[i]);
        // 核心判定：排除 hidden 蜜罐，确保是可见输入框
        if (el && el.type !== 'hidden' && (el.tagName === 'INPUT' || el.tagName === 'TEXTAREA')) {
          el.value = config.data[k];
          // 派发事件：bubbles 保证在 DOM 树中冒泡
          // composed: true 允许事件从 Shadow DOM 内部向外冒泡（若元素位于 shadowRoot 内）
          var evs = ['input', 'change', 'blur'];
          for (var j = 0; j < evs.length; j++) {
            el.dispatchEvent(new Event(evs[j], { bubbles: true, composed: true }));
          }
          filledCount++;
          foundThisRound++;
          break; // 该类目匹配成功即跳出
        }
      }
    }

    if (foundThisRound > 0) {
      showFeedback(filledCount);
      // 填充成功后停止观察，释放性能
      if (observer) { observer.disconnect(); observer = null; }
      return true;
    }
    return false;
  }

  /**
   * 递归穿透 Shadow DOM
   * 普通 querySelector 无法进入 shadowRoot，必须手动下潜
   */
  function deepQuery(root, sel) {
    var el = root.querySelector(sel);
    if (el) return el;
    var all = root.querySelectorAll('*');
    for (var i = 0; i < all.length; i++) {
      if (all[i].shadowRoot) {
        el = deepQuery(all[i].shadowRoot, sel);
        if (el) return el;
      }
    }
    return null;
  }

  /**
   * 初始化：立即执行 + MutationObserver 兜底
   */
  function init() {
    // 立即执行一次
    if (executeFill()) return;

    // 若未找到，监听 DOM 变化（应对异步注入的评论框）
    observer = new MutationObserver(function() {
      if (executeFill() && observer) {
        observer.disconnect();
        observer = null;
      }
    });
    observer.observe(document.body, { childList: true, subtree: true });

    // 10 秒后停止监听，避免长期性能损耗
    setTimeout(function() {
      if (observer) { observer.disconnect(); observer = null; }
    }, 10000);
  }

  /**
   * UI 反馈提示
   */
  function showFeedback(count) {
    var msg = document.getElementById('h-msg') || document.createElement('div');
    msg.id = 'h-msg';
    msg.textContent = '✅ 已填充 ' + count + ' 项字段';
    msg.style.cssText = 'position:fixed;top:20px;right:20px;background:#4CAF50;color:white;padding:12px 24px;border-radius:4px;z-index:999999;font-family:sans-serif;box-shadow:0 2px 10px rgba(0,0,0,0.2);animation:h-fade 3s ease';
    if (!msg.parentNode) document.body.appendChild(msg);
    setTimeout(function() { if(msg.parentNode) msg.parentNode.removeChild(msg); }, 3000);
    if (!document.getElementById('h-style')) {
      var style = document.createElement('style');
      style.id = 'h-style';
      style.textContent = '@keyframes h-fade{0%,100%{opacity:0;transform:translateY(-10px)}15%,85%{opacity:1;transform:translateY(0)}}';
      document.head.appendChild(style);
    }
  }

  // 启动
  init();
})();

三、 可直接使用的书签代码

将上述逻辑压缩成标准 ES5 语法，确保最大兼容性。

操作步骤

1. 在浏览器书签栏右键 → ​添加网页/书签​。

2. ​名称​：填入"自动填表"或"一键评论"。

3. ​网址 (URL)​：完整复制粘贴下方这一行压缩代码：

javascript:(function(){var d={n:'吴蛋蛋',e:'me@wuqishi.com',w:'https://wuqishi.com'},r={n:['#author','#inpName','input[name="author"]','input[placeholder*="昵称"]'],e:['#mail','#email','input[name="email"]','input[placeholder*="邮箱"]'],w:['input[type="url"]','#url','input[name="url"]','input[placeholder*="网址"]']},f=0,o=null;function x(){var a=0;for(var k in r){var s=r[k];for(var i=0;i<s.length;i++){var el=q(document,s[i]);if(el&&el.type!=='hidden'&&(el.tagName==='INPUT'||el.tagName==='TEXTAREA')){el.value=d[k];var v=['input','change','blur'];for(var j=0;j<v.length;j++)el.dispatchEvent(new Event(v[j],{bubbles:true,composed:true}));f++;a++;break}}}if(a>0){y(f);if(o){o.disconnect();o=null}return true}return false}function q(root,sel){var e=root.querySelector(sel);if(e)return e;var a=root.querySelectorAll('*');for(var i=0;i<a.length;i++){if(a[i].shadowRoot){e=q(a[i].shadowRoot,sel);if(e)return e}}return null}function init(){if(x())return;o=new MutationObserver(function(){if(x()&&o){o.disconnect();o=null}});o.observe(document.body,{childList:true,subtree:true});setTimeout(function(){if(o){o.disconnect();o=null}},10000)}function y(c){var m=document.getElementById('h-msg')||document.createElement('div');m.id='h-msg';m.textContent='✅ 已填充 '+c+' 项';m.style.cssText='position:fixed;top:20px;right:20px;background:#4CAF50;color:white;padding:12px 24px;border-radius:4px;z-index:999999;font-family:sans-serif;box-shadow:0 2px 10px rgba(0,0,0,0.2);animation:h-fade 3s ease';if(!m.parentNode)document.body.appendChild(m);setTimeout(function(){if(m.parentNode)m.parentNode.removeChild(m)},3000);if(!document.getElementById('h-style')){var s=document.createElement('style');s.id='h-style';s.textContent='@keyframes h-fade{0%,100%{opacity:0;transform:translateY(-10px)}15%,85%{opacity:1;transform:translateY(0)}}';document.head.appendChild(s)}}init()})();

多身份管理技巧

你可以保存多个书签，每个对应不同身份：

只需修改 config.data​ 里的内容，即可实现"切号"自由。

四、 避坑与进阶

1. 为什么填完点击"提交"会消失？

很多老脚本只改了 value​，没触发事件。Vue/React 等框架监听 input​ 事件来同步状态到内部数据层 。本脚本派发 input​、change​、blur​ 三重事件，确保框架状态树与 DOM 同步。

2. composed: true​ 到底有什么用？

这个参数只在事件从 Shadow DOM 内部向外冒泡时生效。如果目标网站没有使用 Shadow DOM，它是无害的空操作；如果使用了，它确保事件能跨出封装边界被父级监听。

3. 异步注入的兜底逻辑

压缩版中包含了 MutationObserver​，如果首次执行时评论框还没加载（常见于 Valine、Gitalk），它会监听 DOM 变化并在元素出现时自动触发填充，最多观察 10 秒后自动释放。

4. 如何验证脚本是否生效？

打开浏览器开发者工具（F12）→ Console 面板，点击书签后若看到绿色提示框但未生效，可检查：

• 输入框的 id​ 或 name​ 属性是否匹配规则库

• 目标站点是否使用了 closed​ Shadow DOM（无法穿透）

• 是否处于跨域 iframe 内（无法操作）

五、 这套方案无法覆盖的场景

技术方案的诚实边界，是建立互相信任的基础。以下场景目前无法解决：

1. ​跨域 iframe​：如 Disqus、部分版本的畅言，将评论框置于与主站不同源的 iframe 中，受浏览器同源策略限制，任何脚本都无法穿透。

2. ​Closed Shadow DOM​：若第三方组件使用 attachShadow({ mode: 'closed' })​，element.shadowRoot​ 返回 null​，递归穿透失效。

3. ​严格 CSP 限制​：若目标站点配置了禁止内联脚本执行的 Content-Security-Policy​，书签脚本会被浏览器拦截，无绕过方案。

六、附录：常见问题速查 (FAQ)

Q: 这个脚本安全吗？会不会泄露我的信息？

A: 脚本完全在本地浏览器执行，不发送任何网络请求，你的个人信息不会离开本机。

Q: 为什么不用浏览器自带的自动填充功能？

A: 浏览器自动填充依赖表单识别，对中文博客系统的兼容性较差，且无法处理 Shadow DOM 和异步注入场景。

Q: 脚本支持移动端吗？

A: 移动端浏览器（如 Safari、Chrome）同样支持书签脚本，但操作方式略有不同，需通过"添加到主屏幕"或书签栏调用。

Q: 如何为我的自定义主题添加支持？

A: 在 config.rules​ 中追加对应的选择器即可。例如你的主题昵称框 ID 是 nickName​，则添加 '#nickName'​ 到 n​ 数组中。

以上，欢迎给我留评论啊~

‍

本手册旨在帮助管理员理解并快速部署基于 Docker Compose 的 Halo 博客系统。该配置针对 24G 内存服务器 进行了性能优化，并采用了环境变量解耦的安全策略。

🏗️ 1. 核心架构说明

该配置采用典型的 App-DB（应用-数据库）分层架构：

• Halo 容器 (halo_app)：博客主程序，处理业务逻辑、渲染网页。

• PostgreSQL 容器 (halo_db_server)：关系型数据库，存储文章内容、设置、用户信息。

• 虚拟网桥 (halo_internal_net)：创建一个受保护的局域网，使两个容器可以通过名称（如 halodb）互相访问，而不受外部网络干扰。

🛠️ 2. 环境准备（部署前必做）

在宝塔面板或 SSH 终端执行以下步骤，确保基础环境就绪：

① 创建目录并授权

由于 Docker 以 root 权限运行，但内部程序（如 Postgres）有特定的用户 UID，建议预先创建目录并开放读写权限：

# 创建存储数据的根目录
mkdir -p /www/wwwroot/halo/data /www/wwwroot/halo/db

# 赋予最高权限以防止数据库启动失败 (Permission Denied)
chmod -R 777 /www/wwwroot/halo/

② 防火墙放行

在宝塔【安全】或云服务器【安全组】中开放以下端口：

• 8090：博客访问入口。

• 5432：数据库管理入口（若不需要远程连接数据库，可不开放）。

⚙️ 3. 关键配置项深度解析

🔋 性能调优：JVM 内存

- JVM_OPTS=-Xmx2048m -Xms512m

• Xmx (最大堆内存)：2G。在 24G 内存的服务器上，这能确保博客在高并发、处理大量图片插件时依然丝滑，且不会造成系统内存拥堵。

• Xms (初始内存)：512M。启动时即分配，减少初始运行时的内存申请开销。

🛡️ 自愈机制：健康检查 (Healthcheck)

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8090/..."]
  start_period: 60s

• 逻辑：Docker 每 30 秒“问”一次 Halo 是否活着。

• start_period：因为 Java 程序（Spring Boot）冷启动较慢，如果前 60 秒内报错，Docker 会忽略，不会误以为程序崩溃而不断重启。

🌐 域名依赖：External URL

- HALO_EXTERNAL_URL=http://localhost:8090/

• 重要性：这是小白最容易出错的地方。Halo 后台登录需要校验这个地址。如果你绑定了域名（如 https://blog.com），请务必在此处同步修改。

🚀 4. 部署与维护手册

启动命令

在 /www/wwwroot/halo 目录下运行：

docker-compose up -d

状态检查

# 查看容器是否都在运行
docker ps

# 实时查看启动日志（排查报错神器）
docker logs -f halo

如何修改数据库密码？

1. 停止容器：docker-compose down

2. 修改 YAML 中 两个服务 的密码项（必须保持一致）。

3. 注意：如果数据库已经初始化，直接改配置可能无效，建议在首次部署前就确定好强密码。

❓ 5. 常见问题 (FAQ)

Q: 为什么状态显示 Starting 或 Unhealthy？

A: Java 应用启动通常需要 30-60 秒。请使用 docker logs -f halo 查看日志。如果一直卡住，请检查是否为 /www/wwwroot/halo/db 权限不足导致数据库崩溃。

Q: 我可以用 Navicat 连接数据库吗？

A: 可以。使用服务器公网 IP，端口 5432，用户名 halo，密码使用你在配置中设置的值。

Q: 如何更新 Halo 版本？

A: 修改 image 标签中的版本号（如 2.24.1 改为 2.25.0），然后重新运行 docker-compose up -d，Docker 会自动拉取新镜像并平滑更新。如果要保持2.x 最新版，版本号改为2即可。

🌰 6. 完整版配置示例

# ==============================================================================
# 🚀 HALO 2.X 博客系统 - 自动化部署母版 (2026 生产级标准)
# ==============================================================================
# 💡 使用说明：
# 1. 本文件已移除所有隐私（路径、密码、IP），直接复制即可安全分享。
# 2. 采用了 ${变量:-默认值} 格式，即使不配置外部变量也能按默认路径运行。
# 3. 适配宝塔面板、大内存服务器（如 Oracle Cloud 24G 实例）。
# ==============================================================================

services:
  # ----------------------------------------------------------------------------
  # [模块 A] Halo 博客主程序
  # ----------------------------------------------------------------------------
  halo:
    # 镜像地址：官方推荐的稳定版，建议锁定版本号以防自动更新导致数据不兼容
    image: registry.fit2cloud.com/halo/halo:2.24.1
    container_name: halo_app
    restart: always                                 # 策略：服务器重启或程序崩溃时，自动尝试无限次重启
    
    # 启动顺序：必须等下方的 [halodb] 数据库通过健康检查后，博客程序才开始引导
    depends_on:
      halodb:
        condition: service_healthy 

    networks:
      - halo_internal_net                           # 网络：加入内部隔离网络，不与外部无关容器混用

    volumes:
      # 【持久化挂载】：[服务器实际路径] : [容器内部路径]
      # 作用：把你上传的图片、安装的主题、插件存放在服务器硬盘上，容器删了数据还在
      - ${BASE_PATH:-/www/wwwroot/halo}/data:/root/.halo2

    ports:
      # 【端口映射】：[服务器对外端口] : [容器内部端口]
      # 作用：让你通过 http://IP:8090 能够访问到博客
      - "${WEB_PORT:-8090}:8090"

    healthcheck:
      # 【自愈检查】：每 30 秒探测一次后台接口，确保 Java 程序没有假死
      test: ["CMD", "curl", "-f", "http://localhost:8090/actuator/health/readiness"]
      interval: 30s                                 # 检查频率
      timeout: 5s                                   # 响应超时
      retries: 5                                    # 连续失败 5 次则标记为“不健康”并尝试重启
      start_period: 60s                             # 启动缓冲：Java 启动较慢，前 1 分钟不进行强制判定

    environment:
      # 【JVM 调优】：针对 24G 内存机器，分配 2G 运行内存给博客，保证极致流畅
      - JVM_OPTS=-Xmx2048m -Xms512m
      
      # --- 数据库底层连接环境变量 (强制覆盖模式，比 command 更稳) ---
      # 格式：协议://数据库容器名:端口/数据库名
      - SPRING_R2DBC_URL=r2dbc:pool:postgresql://halodb:5432/${DB_NAME:-halo_db}
      - SPRING_R2DBC_USERNAME=${DB_USER:-halo_user}
      - SPRING_R2DBC_PASSWORD=${DB_PASS:-your_strong_password} # 【脱敏：此处填写你的数据库密码】
      - SPRING_SQL_INIT_PLATFORM=postgresql
      
      # 【访问域名】：请在此处填写你的真实访问地址（带 http/https），否则后台无法正常登录
      - HALO_EXTERNAL_URL=${SITE_URL:-http://localhost:8090/}
    
    # 💡 关键：清空默认指令，防止干扰上述 SPRING 环境变量的生效
    command: [] 

  # ----------------------------------------------------------------------------
  # [模块 B] PostgreSQL 数据库引擎
  # ----------------------------------------------------------------------------
  halodb:
    # 镜像地址：使用 alpine 版，不仅体积小（仅约 1/4），且安全性更高
    image: postgres:15-alpine
    container_name: halo_db_server
    restart: always

    networks:
      - halo_internal_net                           # 数据库仅在内部网桥运行，确保公网无法通过容器名攻击

    volumes:
      # 【持久化挂载】：存储所有的文章文字、用户信息、设置项
      - ${BASE_PATH:-/www/wwwroot/halo}/db:/var/lib/postgresql/data

    ports:
      # 【数据库映射】：方便你用 Navicat 或 DBeaver 在电脑本地远程管理数据库
      # 💡 安全建议：如果不需要远程连接，可以将这一行删掉或在防火墙限制 IP
      - "${DB_PORT:-5432}:5432"

    healthcheck:
      # 【就绪判定】：使用官方工具 pg_isready 确保数据库不仅在运行，且可以接受新连接
      test: [ "CMD-SHELL", "pg_isready -U ${DB_USER:-halo_user} -d ${DB_NAME:-halo_db}" ]
      interval: 10s
      timeout: 5s
      retries: 5

    environment:
      # 数据库初始化参数：这些参数必须与上面 [halo] 模块中的配置一一对应
      - POSTGRES_PASSWORD=${DB_PASS:-your_strong_password} # 数据库超级密钥
      - POSTGRES_USER=${DB_USER:-halo_user}               # 数据库登录用户名
      - POSTGRES_DB=${DB_NAME:-halo_db}                   # 默认创建的数据库库名
      - PGUSER=${DB_USER:-halo_user}                      # 指定健康检查所用的用户

# ------------------------------------------------------------------------------
# [模块 C] 网络隔离定义
# ------------------------------------------------------------------------------
networks:
  # 创建一个名为 halo_internal_net 的独立虚拟局域网
  halo_internal_net:
    driver: bridge                                  # 驱动：桥接模式，提供容器间 DNS 自动发现功能

前言

我最近完成了一项“大工程”：将个人博客从传统的 Typecho 平台迁移到了基于 Docker 的 Halo 2.x。

这次迁移并非简单的“搬家”，因为我面临着几个复杂的现实挑战：

1. SEO 权重保卫战：旧文章链接必须通过 301 永久重定向到新路径。

2. 多项目共存：根目录下还有多个独立的 PHP 小工具（如 Speedtest、图片托管等）不能中断。

3. 性能极致追求：利用手头 ARM 4H24G 的高配服务器，实现物理级动静分离。

在反复踩坑 403 错误和 Nginx 配置冲突后，我整理出了这套“终极方案”。

核心挑战与解决方案

1. URL 重定向，比想象中麻烦

Typecho 的文章我使用的路径是 /slug/​，而 Halo 必须要有前缀，综合考虑之后，我决定使用 /p/slug​。为了不让朋友们的收藏夹失效，也不让搜索引擎抓取到 404，我们需要利用 Nginx 的正则匹配实现自动化跳转。以下是需要避坑的地方：

• 有的 URL 末尾带斜杠，有的不带

• 分类页面、独立页面、文章页面的规则全都不一样

• 最坑的是，如果不小心把 /admin​ 也重定向了，后台直接进不去

我一开始用宝塔的反代插件自动生成，结果生成的 rewrite 规则优先级完全不对，要么 404，要么循环重定向。最后干脆放弃插件，直接手写 Nginx 配置。

后面又改回archives​了，主题默认写死了，我太怕麻烦了...

2. 绕过“空目录 403 错误”

由于 Halo 运行在 Docker 容器中，宿主机的网站根目录通常是空的。Nginx 默认会尝试在本地找 index.php​，找不到且禁止列出目录时就会报 403。
方案：在 Nginx 中对首页进行“精确匹配”，直接转发给后端，不经过本地文件系统。

3. 物理级动静分离

Halo 虽然强大，但用 Java 处理静态资源（图片、CSS）效率不如 Nginx。通过 Docker 的卷挂载（Volumes），我们可以让 Nginx 直接读取磁盘上的附件，速度提升显著。

通过 location ~ ^/(themes|plugins|attachments)/​ 块，我们让 Nginx 直接从磁盘读取图片、字体和脚本。这不仅大幅降低了 Halo 容器的 I/O 压力，还通过 Access-Control-Allow-Origin "*"​ 解决了部分主题在预加载字体时可能出现的跨域警告。

4. 解决宝塔保存报错

宝塔面板在保存配置文件时，会扫描 #SSL-START​ 块内是否包含特定的 error_page 404​ 注释行。这也是一个需要注意的地方。

5. 404的问题与解决方案

默认情况下，Nginx 的 proxy_intercept_errors on​ 会直接抛出 Nginx 自带的 404.html​。

方案通过 @seo_logic​ 逻辑：

• 先尝试帮找回旧文章（SEO 补全）。

• 如果确实找不到，则通过 proxy_intercept_errors off​ 再次转发，此时 Nginx 会“闭嘴”，让 Halo 后端吐出主题 404 页面。

终极 Nginx 配置文件

以下是经过多次迭代、能够完美运行在宝塔面板环境下的主配置文件（已脱敏）。

server
{
    listen 80;
    listen 443 ssl;
    http2 on;
    server_name yourdomain.com; # 替换为你的域名
    index index.php index.html index.htm;
    root /www/wwwroot/your_site_folder; # 替换为你的站点根目录
    include /www/server/panel/vhost/nginx/extension/yourdomain.com/*.conf;

    # ==========================================================
    # 【1. 基础 MIME 类型】
    # ==========================================================
    include mime.types;
    types {
        application/javascript        js cjs mjs;
        image/svg+xml                 svg;
    }

    # ==========================================================
    # 【2. SSL 配置区】(保持宝塔兼容性)
    # ==========================================================
    #SSL-START
    #error_page 404/404.html;
    ssl_certificate    /path/to/your/fullchain.pem; # 替换为实际证书路径
    ssl_certificate_key    /path/to/your/privkey.pem;  # 替换为实际密钥路径
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
    ssl_prefer_server_ciphers on;
    # ... 其他 SSL 优化参数 ...
    #SSL-END

    # ==========================================================
    # 【3. 业务路由分发】
    # ==========================================================
    
    # 首页直连
    location = / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $http_host;
        # ... 常用 Proxy Header ...
    }

    # 静态资源直读
    location ~ ^/(themes|plugins|attachments)/ {
        root /www/wwwroot/your_site_folder/data;
        add_header Access-Control-Allow-Origin "*";
        access_log off;
        expires 30d;
        try_files $uri @halo_proxy;
    }

    # 兼容本地 PHP 工具
    location ~ ^/(tool_folder1|tool_folder2) {
        try_files $uri $uri/ /index.php?$query_string;
        include enable-php-83.conf;
    }

    location / {
        try_files $uri $uri/ @halo_proxy;
    }

    # ==========================================================
    # 【4. SEO 重定向映射】
    # ==========================================================
    rewrite ^/feed/?$ /rss.xml permanent;
    rewrite ^/archive/?$ /archives permanent;
    rewrite ^/cross/?$ /moments permanent;
    
    # 标签与分类映射 (请根据实际情况替换 category_name)
    rewrite ^/tag/([^/]+)/?$ /tags/$1 permanent;
    rewrite ^/(category1|category2|category3)/?$ /categories/$1 permanent;

    # ==========================================================
    # 【5. 后端代理与错误拦截】
    # ==========================================================
    location @halo_proxy {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $http_host;
        # ... WebSocket 支持配置 ...

        proxy_intercept_errors on;
        error_page 404 = @seo_logic;
    }

    # ==========================================================
    # 【6. SEO 自动补全逻辑】
    # ==========================================================
    location @seo_logic {
        # 排除列表
        if ($uri ~* "^/(archives/|categories/|tags/|moments|admin|api|login|rss|search|attachments/|themes/|plugins/)") {
            set $fallback "yes";
        }
        
        if ($uri ~* "\.") {
            set $fallback "yes";
        }

        if ($fallback != "yes") {
            rewrite ^/([^/]+)/?$ /archives/$1 permanent;
        }

        # 终极兜底：显示后端自定义 404
        proxy_pass http://127.0.0.1:8090;
        proxy_intercept_errors off;
        proxy_set_header Host $http_host;
    }

    # ==========================================================
    # 【7. 系统错误页】
    # ==========================================================
    #ERROR-PAGE-START
    error_page 502 /502.html;
    # ...
    #ERROR-PAGE-END

    access_log  /www/wwwlogs/yourdomain.com.log;
    error_log  /www/wwwlogs/yourdomain.com.error.log;
}

迁移后的避坑总结

1. 不要依赖宝塔的反向代理插件：对于复杂的 301 跳转需求，插件生成的代码往往会产生优先级冲突。直接修改“配置文件”是最稳妥的选择。

2. 正则排除很重要：在做文章重定向时，务必排除掉 /admin​、/api​ 等 Halo 系统路径，否则你会发现后台无法登录。

3. 权限检查：动静分离使用 alias​ 映射时，确保网站运行用户（通常是 www​）对 Docker 挂载的物理目录有读取权限。

4. JVM 调优：如果你有像我一样充裕的内存（24G），别忘了在 docker-compose.yml​ 中给 Halo 分配足够的内存（如 -Xmx2048m​），这样在处理高并发请求时会更从容。

结语

从 Typecho 到 Halo 的迁移，不只是博客程序的更换，更是对站点架构的一次全面梳理。通过 Nginx 的灵活配置，我们既能享受新程序带来的便利，又能通过“动静分离”和“重定向优化”保障站点的访问体验与搜索权重。

希望这篇指南能帮助你打造一个更稳固、专业的 Halo 博客。修改完成后，记得在宝塔面板中重载 Nginx 配置即可生效，必要时重启一下Nginx！

本文所涉及的 Nginx 配置已在 1.28.3 版本下实测通过。

前言

Typecho 作为经典的 PHP 博客系统，以轻量简洁著称；而 Halo 作为基于 Java 的现代博客平台，在功能丰富度与扩展性上更胜一筹。对我来说 WordPress 过于臃肿、Typecho 过于简陋，而Halo 恰好处于两者的平衡点。

这段时间自己本地搭建体验后感觉真的不错，就试着研究如何迁移。然而，官方迁移插件在导入 Typecho 备份时无法识别数据，社区方案也各有缺陷。最终，基于 fghwett/typecho_to_halo 项目进行定制改造，实现了远程图床场景下的完美迁移。

所以这篇文章将详细介绍如何将 Typecho 的数据（文章、页面、评论、标签、分类等）完整迁移至 Halo，同时保留远程图床链接并自动提取文章封面图。

方案对比：原项目 vs 本方案

核心差异一览

为什么禁用附件迁移？

对于使用又拍云、七牛云等远程图床的博客，附件迁移反而会造成困扰：

1. 存储冗余：远程图片已具备 CDN 加速，无需重复存储至 Halo
2. 性能损耗：下载再上传的过程浪费迁移时间
3. 链接失效风险：迁移过程中可能导致图片链接断裂

解决方案：保留原始图床链接，直接享受 CDN 加速。

为什么添加自动提取封面图？

Halo 支持为文章设置封面图（头图），能显著提升博客的视觉层次感。本方案通过正则表达式自动识别文章中的第一张远程图片，将其设为封面，省去手动配置的繁琐。

• 自动扫描文章内容中的第一张远程图片
• 将其设置为文章的封面图
• 无需手动一一设置，提升迁移效率

本版本更新内容

基于之前版本（2026年4月14日发布），本版本进一步优化了数据迁移的稳定性和用户体验，主要更新包括：

1. 数据去重检查：新增 loadExistingData() 函数，迁移前预加载 Halo 已有数据，通过 slug 对比自动跳过已存在的标签、分类、文章和页面，避免重复导入。
2. 配置完善：更新配置示例，修复目录名称错误，确保与 config-example.yaml 完全一致。
3. 常见问题更新：针对用户反馈，更新了关于数据重复的解答，明确说明工具已具备去重能力。

技术实现：代码改造详解

改造一：禁用附件迁移

文件：apps/migrate/app.go

// 原代码
actions = append(actions, NewAction("迁移附件", app.migrateAttachments))

// 改造后（注释掉该行）
// actions = append(actions, NewAction("迁移附件", app.migrateAttachments))

改造二：新增封面图提取函数

文件：internal/halo/post.go

/**
 * extractFirstImage 从文章内容中提取第一张远程图片URL
 * 支持 Markdown 图片语法：![alt](url)
 * 支持 HTML img 标签：<img src="url">
 * 只提取 http:// 或 https:// 开头的远程图片
 */
func extractFirstImage(content string) string {
    // 匹配 Markdown 图片语法
    mdPattern := `!\[.*?\]\((https?://[^\s\)]+\.(?:jpg|jpeg|png|gif|webp|bmp|svg|ico))`
    mdRe := regexp.MustCompile(mdPattern)
    mdMatches := mdRe.FindStringSubmatch(content)
    if len(mdMatches) > 1 {
        return mdMatches[1]
    }
  
    // 匹配 HTML img 标签
    htmlPattern := `<img[^>]+src=["'](https?://[^"']+\.(?:jpg|jpeg|png|gif|webp|bmp|svg|ico))["']`
    htmlRe := regexp.MustCompile(htmlPattern)
    htmlMatches := htmlRe.FindStringSubmatch(content)
    if len(htmlMatches) > 1 {
        return htmlMatches[1]
    }
  
    return ""
}

改造三：集成封面图至文章迁移

文件：apps/migrate/app.go - migratePosts 函数内

// 提取文章封面图
cover := extractFirstImage(post.Content)

// 创建文章（新增 cover 参数）
postId, err := h.client.AddPost(halo.Post{
    Title:        post.Title,
    Content:      post.Content,
    Slug:         post.Slug,
    Tags:         tags,
    Categories:   categories,
    Status:       status,
    AllowComment: post.AllowComment,
    Cover:        cover,  // 新增封面图字段
}, h.policyName, h.groupName)

改造四：扩展 Post 结构体

文件：internal/halo/post.go

type Post struct {
    Title        string   `json:"title"`
    Content      string   `json:"content"`
    Slug         string   `json:"slug"`
    Tags         []string `json:"tags"`
    Categories   []string `json:"categories"`
    Status       string   `json:"status"`
    AllowComment bool     `json:"allowComment"`
    Cover        string   `json:"cover,omitempty"`  // 新增封面图字段
}

// AddPost 函数内添加封面图设置逻辑
func (c *Client) AddPost(post Post, policyName, groupName string) (string, error) {
    // ... 现有代码 ...
  
    if post.Cover != "" {
        postSetting.Spec.Template = "post"
        postSetting.CustomTemplate = fmt.Sprintf(`{"cover": "%s"}`, post.Cover)
    }
  
    // ... 后续代码 ...
}

迁移工具原理剖析

架构设计

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Typecho DB    │────▶│  typecho_to_halo │────▶│   Halo API      │
│   (MySQL)       │     │   (Go 程序)      │     │   (REST API)    │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                        │                       │
        ▼                        ▼                       ▼
   - tc_contents           - 数据读取              - 创建文章
   - tc_metas              - 结构转换              - 创建分类
   - tc_comments           - API 调用              - 创建标签
   - tc_users              - 错误处理              - 创建评论
   - tc_relationships       - 日志输出              - 设置封面图

数据流转过程

迁移内容清单

环境准备

版本要求

前置检查清单

• Halo 已安装并正常运行
• 已获取 Halo Personal Access Token（路径：Halo 后台 → 用户 → 个人令牌 → 生成新令牌）
• 确认 Typecho 数据库可远程访问
• 记录 Typecho 表前缀（如 tc_ 或默认的 typecho_）

实操步骤

第一步：获取迁移工具

# 克隆仓库（注意是下划线，非连字符）
git clone https://github.com/NoEggEgg/ty2halo.git
cd typecho_to_halo

第二步：配置文件

# 复制示例配置
cp config-example.yaml config.yaml

config.yaml 配置详解：

更新说明：配置格式已更新，与 config-example.yaml 保持完全一致。新增 prefix 字段，优化了配置结构。

typecho:
  type: mysql
  # ⚠️ 必须以斜杠结尾！否则附件下载会报错：lookup xxx.comfiles: no such host
  baseUrl: https://your-domain.com/
  dsn: "username:password@tcp(host:port)/dbname?charset=utf8mb4&parseTime=True&loc=Local"
  prefix: typecho_ # 数据库表前缀，默认为 typecho_
  
halo:
  host: your-halo-host:8090
  schema: http        # 或 https
  token: "your-pat-token"
  debug: false
  policyName: default-policy
  groupName: ""

fileManager:
  dir: ./_tmp/        # 临时文件目录

第三步：处理非默认表前缀

问题现象：若 Typecho 使用 tc_ 而非默认的 typecho_ 前缀，运行时会报错 Table 'dbname.typecho_metas' doesn't exist。

解决方案：在 MySQL 中创建视图映射

USE your_database_name;

-- 创建视图映射（将 tc_* 映射为 typecho_*）
CREATE OR REPLACE VIEW typecho_metas AS SELECT * FROM tc_metas;
CREATE OR REPLACE VIEW typecho_contents AS SELECT * FROM tc_contents;
CREATE OR REPLACE VIEW typecho_comments AS SELECT * FROM tc_comments;
CREATE OR REPLACE VIEW typecho_users AS SELECT * FROM tc_users;
CREATE OR REPLACE VIEW typecho_options AS SELECT * FROM tc_options;
CREATE OR REPLACE VIEW typecho_fields AS SELECT * FROM tc_fields;
CREATE OR REPLACE VIEW typecho_relationships AS SELECT * FROM tc_relationships;

清理视图（迁移完成后执行）：

USE your_database_name;

DROP VIEW IF EXISTS typecho_metas;
DROP VIEW IF EXISTS typecho_contents;
DROP VIEW IF EXISTS typecho_comments;
DROP VIEW IF EXISTS typecho_users;
DROP VIEW IF EXISTS typecho_options;
DROP VIEW IF EXISTS typecho_fields;
DROP VIEW IF EXISTS typecho_relationships;

第四步：执行迁移

方式一：使用预编译版本（推荐）

# Windows
ty2halo.exe

# Linux / macOS
./ty2halo

方式二：自行编译

go mod tidy
go build -o ty2halo.exe

迁移执行顺序：

1. ✅ 迁移标签
2. ✅ 迁移分类
3. ❌ 迁移附件 （已禁用）
4. ✅ 迁移文章（自动提取封面图）
5. ✅ 迁移页面
6. ✅ 迁移评论

验证与验收

登录 Halo 后台核对数据完整性：

常见问题速查

Q1：重复数据如何处理？

现象：多次运行后标签/分类重复。

原因： 工具未做重复检测。 更新：工具已添加数据去重检查。

解决：

• 在 Halo 后台删除重复数据后重新运行
• 或修改源码添加存在性检查（需重新编译）
• 新增：工具已内置数据去重功能，会先查询 Halo 中已存在的数据（通过 slug 对比），自动跳过已存在的标签、分类、文章和页面。但如果手动删除 Halo 数据后重新迁移，仍然会正常导入。

Q2：附件下载报错 lookup xxx.comfiles: no such host

原因：baseUrl 缺少末尾斜杠，导致 URL 拼接错误。

解决：确保 baseUrl 以 / 结尾，如 https://example.com/。

Q3：表前缀不匹配

解决：使用上述数据库视图方案，或修改源码中的表名常量。

Q4：如何恢复附件迁移功能？

如需将附件下载至 Halo 本地（不推荐远程图床场景）：

// apps/migrate/app.go
// 取消注释以下行
actions = append(actions, NewAction("迁移附件", app.migrateAttachments))

Q5：封面图提取规则是什么？

总结

通过定制化的 ty2halo 工具，我们实现了：

后续

这篇文章会持续更新，因为迁移后还有各种其他问题需要调试，比如固定链接等，有点小麻烦。

最后更新：2026年4月20日（添加数据去重检查等优化）

参考资源

• 仓库地址：https://github.com/NoEggEgg/ty2halo
• 原项目仓库地址：https://github.com/fghwett/typecho_to_halo
• Halo 官方文档：https://docs.halo.run
• Typecho 官方网站：https://typecho.org

‍

CodeBuddy 技能配置：218个技能覆盖开发流程、数据处理、微信生态等10大场景，包含从 addyosmani/agent-skills 引入的19个生产级工程技能及完整使用心得。

前言

使用 AI 编程助手已经一年多了，从最初的简单问答，到现在的全流程开发辅助，核心在于技能的积累与配置。

今天把我正在使用的 62 个用户技能 + 156 个市场技能整理成文，分享我的配置思路与使用场景。

一、为什么技能比模型更重要？

模型 = 能力基础
技能 = 专精领域
配置 = 工作流程

同样的模型，装载不同的技能，就是不同的专家角色：

• 加载 code-review-and-quality → 资深代码审查员
• 加载 security-and-hardening → 安全工程师
• 加载 planning-and-task-breakdown → 项目架构师

二、用户技能完整清单 (62个)

位于：~/.codebuddy/skills/

⚡ 开发流程 (19个) ⭐核心技能

这是从 addyosmani/agent-skills 引入的生产级工程技能！

需求到发布完整链路

📊 数据处理 (6个)

🎨 内容创作 (6个)

💬 微信生态 (6个)

🖼️ 图像处理 (3个)

🔍 搜索工具 (3个)

🛠️ 效率工具 (7个)

🧠 AI助手进化 (5个)

📱 社交媒体 (1个)

🏢 办公套件 (2个)

🎨 设计/UI (1个)

🔄 系统/工具 (2个)

🧪 测试 (1个)

三、市场技能完整清单 (156个)

位于：~/.codebuddy/skills-marketplace/skills/

🔧 开发工具 (38个)

📱 微信/小程序 (9个)

🗺️ 地图/位置服务 (5个)

📊 数据/金融 (12个)

📝 文档/笔记 (14个)

🎬 媒体/视频 (12个)

📧 邮件/日历 (6个)

🤖 Agent/AI (20个)

🔒 安全/质量 (4个)

💼 商业/营销 (15个)

📈 销售/客户 (7个)

🌐 搜索/文档 (6个)

🎓 学习/研究 (4个)

☁️ 云服务/集成 (4个)

🎯 其他工具 (7个)

四、配置文件结构

与备份导出目录结构完全一致

CodeBuddy-Full-Backup/
├── README.md                    # 导入说明文档
├── settings.json                # CodeBuddy 全局配置
├── hooks-config.json            # 生命周期钩子配置
├── 01-user-skills/              # 用户安装的技能 (62个)
│   ├── agent-browser/
│   ├── ai-data-analysis/
│   ├── ai-ppt-generator/
│   ├── api-and-interface-design/
│   ├── auto-updater/
│   ├── baidu-search/
│   ├── browser-testing-with-devtools/
│   ├── ci-cd-and-automation/
│   ├── code-review-and-quality/
│   ├── code-simplification/
│   ├── code-standard/           # ⭐ 自定义代码规范
│   ├── context-engineering/
│   ├── copywriter/
│   ├── data-analyst/
│   ├── debugging-and-error-recovery/
│   ├── deprecation-and-migration/
│   ├── documentation-and-adrs/
│   ├── excel-weekly-dashboard/
│   ├── excel-xlsx/
│   ├── frontend-ui-engineering/
│   ├── github/
│   ├── git-workflow-and-versioning/
│   ├── humanize-ai-text/
│   ├── humanizer/
│   ├── humanizer-zh/
│   ├── idea-refine/
│   ├── image/
│   ├── image-cog/
│   ├── incremental-implementation/
│   ├── markdown-converter/
│   ├── marketing-mode/
│   ├── memory-manager/
│   ├── nano-banana-pro/
│   ├── office/
│   ├── openclaw-tavily-search/
│   ├── performance-optimization/
│   ├── planning-and-task-breakdown/
│   ├── proactive-agent/
│   ├── security-and-hardening/
│   ├── self-improving-agent/
│   ├── seo/
│   ├── sheet-cog/
│   ├── sheetsmith/
│   ├── shipping-and-launch/
│   ├── skill-vetter/
│   ├── spec-driven-development/
│   ├── summarize/
│   ├── system-data-intelligence/
│   ├── test-driven-development/
│   ├── test-user-skill/
│   ├── ui-ux-pro-max/
│   ├── using-agent-skills/
│   ├── web-search/
│   ├── wechat/
│   ├── wechat-article-search/
│   ├── wechat-auto-reply/
│   ├── wechat-mp-cn/
│   ├── wechat-mp-writer-skill-mxx/
│   ├── wechat-sender/
│   ├── wps-office/
│   ├── xhs/
│   └── xlsx-pro/
└── 02-marketplace-skills/       # 市场技能 (156个)
    └── skills/
        ├── admapix/
        ├── agent-browser-core/
        ├── agent-mail/
        ├── agent-mbti/
        ├── agent-team-orchestration/
        ├── andonq/
        ├── android-native-dev/
        ├── anti-distill/
        ├── api-gateway/
        ├── apple-notes/
        ├── apple-reminders/
        ├── arxiv-reader/
        ├── arxiv-watcher/
        ├── autoresearch/
        ├── awesome-design-md/
        ├── blogwatcher/
        ├── boss-skills/
        ├── brand-guidelines/
        ├── browser/
        ├── browser-cash/
        ├── browser-use/
        ├── browserwing/
        ├── caldav-calendar/
        ├── canvas-design/
        ├── capability-evolver/
        ├── citation-manager/
        ├── clawbrowser/
        ├── cli-anything-hub/
        ├── cloudbase/
        ├── cloudq/
        ├── cnb-skill/
        ├── colleague-skill/
        ├── content-factory/
        ├── content-ops/
        ├── content-repurposer/
        ├── conversion-ops/
        ├── cos-vectors/
        ├── deck-generator/
        ├── deep-research/
        ├── didi-ride-skill/
        ├── earnings-tracker/
        ├── education/
        ├── email-skill/
        ├── FBS-BookWriter/
        ├── finance-ops/
        ├── find-skills/
        ├── fintech-engineer/
        ├── flutter-dev/
        ├── frontend-dev/
        ├── fullstack-dev/
        ├── gifgrep/
        ├── gif-sticker-maker/
        ├── github/
        ├── github-ai-trends/
        ├── github-trending-cn/
        ├── goal-tracker/
        ├── gog/
        ├── growth-engine/
        ├── habit-tracker/
        ├── healthcheck/
        ├── himalaya/
        ├── humanizer/
        ├── idea-validator/
        ├── imap-smtp-email/
        ├── ima-skills/
        ├── impeccable/
        ├── imsg/
        ├── ios-application-dev/
        ├── lark-unified/
        ├── lexiang-knowledge-base/
        ├── llm-wiki/
        ├── macro-monitor/
        ├── marketing-skills/
        ├── market-researcher/
        ├── mcp-builder/
        ├── mcporter/
        ├── migraq/
        ├── minimax-docx/
        ├── minimax-pdf/
        ├── minimax-xlsx/
        ├── model-usage/
        ├── multi-search-engine/
        ├── nano-banana-pro/
        ├── nano-pdf/
        ├── neodata-financial-search/
        ├── news-summary/
        ├── notebooklm-studio/
        ├── note-organizer/
        ├── obsidian/
        ├── openai-image-gen/
        ├── openai-whisper/
        ├── openai-whisper-api/
        ├── openclaw-assets-to-workbuddy/
        ├── open-lesson/
        ├── oracle/
        ├── outbound-engine/
        ├── peekaboo/
        ├── perplexity/
        ├── playwright-browser-automation/
        ├── playwright-scraper-skill/
        ├── podcast-ops/
        ├── pptx-generator/
        ├── prompt-engineering-expert/
        ├── qmd/
        ├── qq-email/
        ├── react-native-dev/
        ├── remotion-video-toolkit/
        ├── revenue-intelligence/
        ├── sag/
        ├── sales-pipeline/
        ├── sales-playbook/
        ├── seo-ops/
        ├── shader-dev/
        ├── skill-creator/
        ├── skill-scanner/
        ├── skills-security-check/
        ├── skill-vetter/
        ├── skyline/
        ├── smooth-browser/
        ├── songsee/
        ├── stagehand-browser-cli/
        ├── stealth-browser/
        ├── summarize/
        ├── tapd-openapi/
        ├── tdesign-miniprogram/
        ├── team-ops/
        ├── tencentcloud-cos/
        ├── tencent-docs/
        ├── tencentmap-jsapi-gl-skill/
        ├── tencentmap-lbs-skill/
        ├── tencentmap-miniprogram-skill/
        ├── tencentmap-webservice-skill/
        ├── tencent-meeting-skill/
        ├── tencent-news/
        ├── tencent-ssv-techforgood/
        ├── tencent-survey/
        ├── things-mac/
        ├── tmux/
        ├── trello/
        ├── tutor-skills/
        ├── video-frames/
        ├── wacli/
        ├── weather/
        ├── web-access/
        ├── web-scraper/
        ├── web-search-exa/
        ├── wechat-article-search/
        ├── wechat-miniprogram/
        ├── wechatpay-basic-payment/
        ├── wechatpay-product-coupon/
        ├── weiyun/
        ├── x-longform-post/
        ├── xurl/
        ├── yourself-skill/
        ├── yt-competitive-analysis/
        └── zenstudio/

五、技能更新管理

技能来源不同，更新方式也有所区别。

5.1 更新类型分类

5.2 有元数据的市场技能（自动更新）

判断依据：技能目录下存在 _meta.json 文件

{
  "ownerId": "kn7agvhxan0vcwfmhrjhwg4n9s802d7k",
  "slug": "proactive-agent",
  "version": "3.1.0",
  "publishedAt": 1770259214202
}

更新方式：

1. 打开 CodeBuddy 集成界面
2. 进入技能市场
3. 点击「检查更新」或「更新全部」

已配置自动更新的用户技能（40个）：

5.3 agent-skills（GitHub 手动更新）

19个技能列表：

GitHub 仓库：https://github.com/addyosmani/agent-skills

手动更新命令：

# 1. 克隆最新版本到临时目录
git clone --depth 1 https://github.com/addyosmani/agent-skills.git "$env:TEMP\agent-skills-new"

# 2. 备份旧版本
$backupPath = "$env:USERPROFILE\.codebuddy\skills-agent-skills-backup"
Copy-Item -Path "$env:USERPROFILE\.codebuddy\skills\planning-and-task-breakdown" -Destination $backupPath -Recurse

# 3. 替换更新
Copy-Item -Path "$env:TEMP\agent-skills-new\skills\*" -Destination "$env:USERPROFILE\.codebuddy\skills" -Recurse -Force

# 4. 清理
Remove-Item -Path "$env:TEMP\agent-skills-new" -Recurse -Force

查看最新版本：

# 查看远程最新提交
git ls-remote https://github.com/addyosmani/agent-skills.git HEAD

5.4 用户自定义技能（自行维护）

技能名称：code-standard

配置文件：~/.codebuddy/skills/code-standard/SKILL.md

更新方式：

1. 根据实际使用反馈手动修改
2. 参考官方技能结构优化
3. 定期复盘并更新规则

维护建议：

• 在文件末尾的「迭代记录」区域记录每次改进
• 保持简洁原则，避免过度复杂化
• 遇到新的最佳实践时及时更新

5.5 一键更新脚本

# === CodeBuddy Skills 一键更新脚本 ===

$skillsPath = "$env:USERPROFILE\.codebuddy\skills"
$tempPath = "$env:TEMP\codebuddy-update-$(Get-Random)"

Write-Host "🔄 开始更新技能..." -ForegroundColor Cyan

# 1. 更新 agent-skills
Write-Host "`n📦 更新 agent-skills (19个)..." -ForegroundColor Yellow
git clone --depth 1 https://github.com/addyosmani/agent-skills.git "$tempPath\agent-skills" -q
if (Test-Path "$tempPath\agent-skills\skills") {
    Get-ChildItem "$tempPath\agent-skills\skills" | ForEach-Object {
        $targetPath = "$skillsPath\$($_.Name)"
        if (Test-Path $targetPath) {
            Remove-Item $targetPath -Recurse -Force
        }
        Copy-Item $_.FullName -Destination $skillsPath -Recurse -Force
    }
    Write-Host "✅ agent-skills 更新完成" -ForegroundColor Green
}

# 2. 提示市场技能更新
Write-Host "`n🛒 请手动在 CodeBuddy 市场检查更新" -ForegroundColor Cyan
Write-Host "   路径：集成 → 技能市场 → 检查更新`n" -ForegroundColor Gray

# 3. 清理
if (Test-Path $tempPath) {
    Remove-Item $tempPath -Recurse -Force
}

Write-Host "✨ 更新完成！" -ForegroundColor Green

5.6 更新检查清单

六、导入方法

方式一：完整导入（推荐）

# 1. 解压备份文件到临时目录
# 2. 复制到用户配置目录

# 复制用户技能
Copy-Item -Path "01-user-skills" -Destination "$env:USERPROFILE\.codebuddy\skills" -Recurse -Force

# 复制市场技能
Copy-Item -Path "02-marketplace-skills" -Destination "$env:USERPROFILE\.codebuddy\" -Recurse -Force

# 复制配置文件
Copy-Item -Path "settings.json" -Destination "$env:USERPROFILE\.codebuddy\"

方式二：选择性导入

# 只导入用户技能
Copy-Item -Path "01-user-skills" -Destination "$env:USERPROFILE\.codebuddy\skills" -Recurse -Force

# 只导入某个特定技能
Copy-Item -Path "01-user-skills\code-standard" -Destination "$env:USERPROFILE\.codebuddy\skills\code-standard" -Recurse -Force

七、效果对比

八、总结

技能是 AI 助手的"肌肉记忆" —— 通过预置的工作流程和专业领域知识，让 AI 在特定场景下表现出专家水平。

配置建议：

• ✅ 优先配置开发流程类技能（19个）
• ✅ 根据日常需求选择垂直领域技能
• ✅ 创建个人规范保持风格一致
• ✅ 定期回顾，删除不用的技能

九、统计数据

本文由 AI 编程助手辅助生成，技能配置让输出更专业

‍

写在最后

不知道有多少人会看到这里，但我这个博客的定位始终如一：整理我能整理的，分享我所分享的。

关于 AI，或许有人会误解——觉得依赖 AI 就失去了主观能动性，人会变得越来越懒。但这篇文章的诞生，其实经历了这样的过程：

1. 构思：我需要明确分享什么，拟定核心主旨。
2. 结构：我喜欢「总-分-总」的形式，所以我的文章常有前言/写在前面，后记/写在最后。这篇文章也是我给AI拟定的结构，包括用户技能和市场技能分开介绍。
3. 调整：AI 生成的内容，我会逐字逐句阅读，我觉得别扭、不完善、未表达清楚观点的地方我会进行修改。整个过程至少打磨了 5-6 轮。
4. 发布：哦，这没什么说的...
5. 总结反思：个人精力、能力毕竟有限，所以AI某些方面确实更优秀。文章生成后的阅读与一次次调整的过程，也是自我提升的过程。

对于使用AI我的个人见解是：工具就是拿来用的，要让工具成为我们的武器。与其畏惧变化，不如大步拥抱向前。

本来对于评论的自定义表情没有太多想法，毕竟评论的主体是评论本身嘛。奈何这套表情真的是太好看了…

General basic facial stickers suitable for most websites and applications.

适用于大多数网站和应用程序的通用基础面部贴纸。

版权事宜

This expression is not authorized to be used by non-business bloggers only. Authorization is required for the rest of the way, please note.

此表达方式仅限非商业博主使用，未经授权不得使用。请注意，后续使用均需获得授权。

个人非盈利博客，免授权哦。

表情预览

项目地址

Sticker-Heo：https://github.com/zhheo/Sticker-Heo

怎么使用

Twikoo

https://cdn.jsdelivr.net/npm/sticker-heo@2022.7.5/twikoo.json

Valine

https://cdn.jsdelivr.net/npm/sticker-heo@2022.7.5/valine.json

Waline

在表情符号选项中添加配置项：

emoji: [
    'https://cdn.jsdelivr.net/npm/sticker-heo@2022.7.5/Sticker-100/',
]

Artalk

https://cdn.jsdelivr.net/npm/sticker-heo@2022.7.5/artalk.json

在handsome主题中怎么用呢？

表情上传

把表情传到主题目录下的​​assets/img/emotion​文件夹中。

• 如果表情的静态资源存在你自己的外部CDN，并且配置了「静态资源加速」，但是此时本地服务器也需要存储一份，因为需要检查对应的图片文件是否存在来决定是否解析表情。
• 也就是说，本地服务器和远程CDN的这个文件夹都要传

配置文件修改

需要修改主题目录下面的usr/OwO.json文件：

"新的表情栏目名称": {
    "name": "表情包文件夹名称",
    "type": "image",
    "container": [
        {
            "icon": "图片名称",
            "text": "提示文字"
        },
    ]
}

我的配置文件

你是不是盯上了我写好的配置？众乐乐吧：

{
  "Heo": {
    "type": "image",
    "name": "biaoqing",
    "container": [
      {
        "icon": "害羞",
        "text": "害羞"
      },
      {
        "icon": "呲牙笑",
        "text": "呲牙笑"
      },
      {
        "icon": "喜欢",
        "text": "喜欢"
      },
      {
        "icon": "奋斗",
        "text": "奋斗"
      },
      {
        "icon": "耍酷",
        "text": "耍酷"
      },
      {
        "icon": "烦恼",
        "text": "烦恼"
      },
      {
        "icon": "爆炸",
        "text": "爆炸"
      },
      {
        "icon": "熬夜",
        "text": "熬夜"
      },
      {
        "icon": "吃瓜",
        "text": "吃瓜"
      },
      {
        "icon": "阴险",
        "text": "阴险"
      },
      {
        "icon": "滑稽",
        "text": "滑稽"
      },
      {
        "icon": "被打",
        "text": "被打"
      },
      {
        "icon": "大笑",
        "text": "大笑"
      },
      {
        "icon": "亲亲",
        "text": "亲亲"
      },
      {
        "icon": "愤怒",
        "text": "愤怒"
      },
      {
        "icon": "惊吓",
        "text": "惊吓"
      },
      {
        "icon": "尴尬",
        "text": "尴尬"
      },
      {
        "icon": "捂嘴笑",
        "text": "捂嘴笑"
      },
      {
        "icon": "捂脸",
        "text": "捂脸"
      },
      {
        "icon": "生病",
        "text": "生病"
      },
      {
        "icon": "绿帽",
        "text": "绿帽"
      },
      {
        "icon": "鼓掌",
        "text": "鼓掌"
      },
      {
        "icon": "抠鼻",
        "text": "抠鼻"
      },
      {
        "icon": "感动",
        "text": "感动"
      },
      {
        "icon": "吐血",
        "text": "吐血"
      },
      {
        "icon": "鬼脸",
        "text": "鬼脸"
      },
      {
        "icon": "擦汗",
        "text": "擦汗"
      },
      {
        "icon": "惊讶",
        "text": "惊讶"
      },
      {
        "icon": "恶心",
        "text": "恶心"
      },
      {
        "icon": "禁言",
        "text": "禁言"
      },
      {
        "icon": "睡觉",
        "text": "睡觉"
      },
      {
        "icon": "笑哭",
        "text": "笑哭"
      },
      {
        "icon": "思考",
        "text": "思考"
      },
      {
        "icon": "疑问",
        "text": "疑问"
      },
      {
        "icon": "吵架",
        "text": "吵架"
      },
      {
        "icon": "眩晕",
        "text": "眩晕"
      },
      {
        "icon": "再见",
        "text": "再见"
      },
      {
        "icon": "微笑",
        "text": "微笑"
      },
      {
        "icon": "哭泣",
        "text": "哭泣"
      },
      {
        "icon": "开心",
        "text": "开心"
      },
      {
        "icon": "加班",
        "text": "加班"
      },
      {
        "icon": "唱歌",
        "text": "唱歌"
      },
      {
        "icon": "纠结",
        "text": "纠结"
      },
      {
        "icon": "发红包",
        "text": "发红包"
      },
      {
        "icon": "送福",
        "text": "送福"
      },
      {
        "icon": "牛年进宝",
        "text": "牛年进宝"
      },
      {
        "icon": "头秃",
        "text": "头秃"
      },
      {
        "icon": "我看好你",
        "text": "我看好你"
      },
      {
        "icon": "好的",
        "text": "好的"
      },
      {
        "icon": "好奇",
        "text": "好奇"
      },
      {
        "icon": "偷偷看",
        "text": "偷偷看"
      },
      {
        "icon": "危险",
        "text": "危险"
      },
      {
        "icon": "小丑",
        "text": "小丑"
      },
      {
        "icon": "引起不适",
        "text": "引起不适"
      },
      {
        "icon": "滑稽喝水",
        "text": "滑稽喝水"
      },
      {
        "icon": "打牌",
        "text": "打牌"
      },
      {
        "icon": "应援",
        "text": "应援"
      },
      {
        "icon": "疼痛",
        "text": "疼痛"
      },
      {
        "icon": "勉强笑",
        "text": "勉强笑"
      },
      {
        "icon": "看穿一切",
        "text": "看穿一切"
      },
      {
        "icon": "滑稽狂汗",
        "text": "滑稽狂汗"
      },
      {
        "icon": "不好意思",
        "text": "不好意思"
      },
      {
        "icon": "难以置信",
        "text": "难以置信"
      },
      {
        "icon": "滑稽被子",
        "text": "滑稽被子"
      },
      {
        "icon": "月饼",
        "text": "月饼"
      },
      {
        "icon": "手机相机",
        "text": "手机相机"
      },
      {
        "icon": "倚墙笑",
        "text": "倚墙笑"
      },
      {
        "icon": "出家人",
        "text": "出家人"
      },
      {
        "icon": "黑线",
        "text": "黑线"
      },
      {
        "icon": "呦吼",
        "text": "呦吼"
      },
      {
        "icon": "扶额",
        "text": "扶额"
      },
      {
        "icon": "打咩",
        "text": "打咩"
      },
      {
        "icon": "有没有搞错",
        "text": "有没有搞错"
      },
      {
        "icon": "深思",
        "text": "深思"
      },
      {
        "icon": "3d眼镜",
        "text": "3d眼镜"
      },
      {
        "icon": "电话",
        "text": "电话"
      },
      {
        "icon": "托腮",
        "text": "托腮"
      },
      {
        "icon": "裂开",
        "text": "裂开"
      },
      {
        "icon": "滑稽柠檬",
        "text": "滑稽柠檬"
      },
      {
        "icon": "伞兵",
        "text": "伞兵"
      },
      {
        "icon": "胡子",
        "text": "胡子"
      },
      {
        "icon": "小偷",
        "text": "小偷"
      },
      {
        "icon": "智慧的眼神",
        "text": "智慧的眼神"
      },
      {
        "icon": "滑稽奶茶",
        "text": "滑稽奶茶"
      },
      {
        "icon": "送花",
        "text": "送花"
      },
      {
        "icon": "失望",
        "text": "失望"
      },
      {
        "icon": "吃手",
        "text": "吃手"
      },
      {
        "icon": "嘿哈",
        "text": "嘿哈"
      },
      {
        "icon": "LPL",
        "text": "LPL"
      },
      {
        "icon": "抬眼镜",
        "text": "抬眼镜"
      },
      {
        "icon": "泪奔",
        "text": "泪奔"
      },
      {
        "icon": "EDG",
        "text": "EDG"
      },
      {
        "icon": "傻笑",
        "text": "傻笑"
      },
      {
        "icon": "拜托",
        "text": "拜托"
      },
      {
        "icon": "这是啥",
        "text": "这是啥"
      },
      {
        "icon": "波吉",
        "text": "波吉"
      },
      {
        "icon": "惬意",
        "text": "惬意"
      },
      {
        "icon": "没招",
        "text": "没招"
      },
      {
        "icon": "放鞭炮",
        "text": "放鞭炮"
      },
      {
        "icon": "财神红包",
        "text": "财神红包"
      },
      {
        "icon": "痛哭",
        "text": "痛哭"
      },
      {
        "icon": "尬笑",
        "text": "尬笑"
      },
      {
        "icon": "流汗微笑",
        "text": "流汗微笑"
      },
      {
        "icon": "整理发型",
        "text": "整理发型"
      },
      {
        "icon": "击剑",
        "text": "击剑"
      },
      {
        "icon": "缺牙笑",
        "text": "缺牙笑"
      }
    ]
  },
  "狗头": {
    "type": "image",
    "name": "biaoqing",
    "container": [
      {
        "icon": "狗头",
        "text": "狗头"
      },
      {
        "icon": "哈士奇",
        "text": "哈士奇"
      },
      {
        "icon": "狗头围脖",
        "text": "狗头围脖"
      },
      {
        "icon": "狗头花",
        "text": "狗头花"
      },
      {
        "icon": "狗头草",
        "text": "狗头草"
      },
      {
        "icon": "狗头胖次",
        "text": "狗头胖次"
      },
      {
        "icon": "熊猫",
        "text": "熊猫"
      },
      {
        "icon": "熊猫唱歌",
        "text": "熊猫唱歌"
      },
      {
        "icon": "哈士奇失去意识",
        "text": "哈士奇失去意识"
      },
      {
        "icon": "熊猫喜欢",
        "text": "熊猫喜欢"
      },
      {
        "icon": "菜狗",
        "text": "菜狗"
      },
      {
        "icon": "菜狗花",
        "text": "菜狗花"
      },
      {
        "icon": "狗头失望",
        "text": "狗头失望"
      },
      {
        "icon": "哈士奇失望",
        "text": "哈士奇失望"
      },
      {
        "icon": "熊猫失望",
        "text": "熊猫失望"
      },
      {
        "icon": "熊猫意外",
        "text": "熊猫意外"
      },
      {
        "icon": "狗头意外",
        "text": "狗头意外"
      },
      {
        "icon": "猪头",
        "text": "猪头"
      },
      {
        "icon": "猪头意外",
        "text": "猪头意外"
      },
      {
        "icon": "恶魔",
        "text": "恶魔"
      },
      {
        "icon": "恶魔恐惧",
        "text": "恶魔恐惧"
      },
      {
        "icon": "beluga",
        "text": "beluga"
      },
      {
        "icon": "老虎意外",
        "text": "老虎意外"
      },
      {
        "icon": "虎年进宝",
        "text": "虎年进宝"
      }
    ]
  },
  "颜文字": {
    "type": "emoticon",
    "container": [
      {
        "icon": "OωO",
        "text": "Author: DIYgod"
      },
      {
        "icon": "|´・ω・)ノ",
        "text": "Hi"
      },
      {
        "icon": "ヾ(≧∇≦*)ゝ",
        "text": "开心"
      },
      {
        "icon": "(☆ω☆)",
        "text": "星星眼"
      },
      {
        "icon": "（╯‵□′）╯︵┴─┴",
        "text": "掀桌"
      },
      {
        "icon": "￣﹃￣",
        "text": "流口水"
      },
      {
        "icon": "(/ω＼)",
        "text": "捂脸"
      },
      {
        "icon": "∠( ᐛ 」∠)＿",
        "text": "给跪"
      },
      {
        "icon": "(๑•̀ㅁ•́ฅ)",
        "text": "Hi"
      },
      {
        "icon": "→_→",
        "text": "斜眼"
      },
      {
        "icon": "୧(๑•̀⌄•́๑)૭",
        "text": "加油"
      },
      {
        "icon": "٩(ˊᗜˋ*)و",
        "text": "有木有WiFi"
      },
      {
        "icon": "(ノ°ο°)ノ",
        "text": "前方高能预警"
      },
      {
        "icon": "(´இ皿இ｀)",
        "text": "我从未见过如此厚颜无耻之人"
      },
      {
        "icon": "⌇●﹏●⌇",
        "text": "吓死宝宝惹"
      },
      {
        "icon": "(ฅ´ω`ฅ)",
        "text": "已阅留爪"
      },
      {
        "icon": "(╯°A°)╯︵○○○",
        "text": "去吧大师球"
      },
      {
        "icon": "φ(￣∇￣o)",
        "text": "太萌惹"
      },
      {
        "icon": "ヾ(´･ ･｀｡)ノ\"",
        "text": "咦咦咦"
      },
      {
        "icon": "( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃",
        "text": "气呼呼"
      },
      {
        "icon": "(ó﹏ò｡)",
        "text": "我受到了惊吓"
      },
      {
        "icon": "Σ(っ °Д °;)っ",
        "text": "什么鬼"
      },
      {
        "icon": "( ,,´･ω･)ﾉ\"(´っω･｀｡)",
        "text": "摸摸头"
      },
      {
        "icon": "╮(╯▽╰)╭ ",
        "text": "无奈"
      },
      {
        "icon": "o(*////▽////*)q ",
        "text": "脸红"
      },
      {
        "icon": "＞﹏＜",
        "text": ""
      },
      {
        "icon": "( ๑´•ω•) \"(ㆆᴗㆆ)",
        "text": ""
      },
      {
        "icon": "(｡•ˇˇ•｡)",
        "text": ""
      }
    ]
  },
  "阿鲁": {
    "name": "aru",
    "type": "image",
    "container": [
      {
        "icon": "despise",
        "text": "鄙视"
      },
      {
        "icon": "knife",
        "text": "插刀"
      },
      {
        "icon": "pouting",
        "text": "亲嘴"
      },
      {
        "icon": "shutup",
        "text": "闭嘴"
      },
      {
        "icon": "unhappy",
        "text": "不开心"
      },
      {
        "icon": "discovertruth",
        "text": "发现真相"
      },
      {
        "icon": "shit",
        "text": "便便"
      },
      {
        "icon": "distressed",
        "text": "烦恼"
      },
      {
        "icon": "shy",
        "text": "捂脸"
      },
      {
        "icon": "speechless",
        "text": "无语"
      },
      {
        "icon": "confuse",
        "text": "迷惑"
      },
      {
        "icon": "frown",
        "text": "皱眉"
      },
      {
        "icon": "proud",
        "text": "得意"
      },
      {
        "icon": "cheer",
        "text": "欢呼"
      },
      {
        "icon": "meditation",
        "text": "沉思"
      },
      {
        "icon": "diving",
        "text": "潜水"
      },
      {
        "icon": "cryingface",
        "text": "掩面哭泣"
      },
      {
        "icon": "lurking",
        "text": "潜伏"
      },
      {
        "icon": "thumb",
        "text": "大拇指"
      },
      {
        "icon": "smile",
        "text": "微笑"
      },
      {
        "icon": "clap",
        "text": "拍掌"
      },
      {
        "icon": "envious",
        "text": "眼馋"
      },
      {
        "icon": "surrender",
        "text": "投降"
      },
      {
        "icon": "bigeye",
        "text": "大眼睛"
      },
      {
        "icon": "nose",
        "text": "抠鼻"
      },
      {
        "icon": "sweat",
        "text": "流汗"
      },
      {
        "icon": "flower",
        "text": "小花花"
      },
      {
        "icon": "crying",
        "text": "流泪"
      },
      {
        "icon": "spit",
        "text": "吐"
      },
      {
        "icon": "surprised",
        "text": "吃惊"
      },
      {
        "icon": "blood",
        "text": "一滩血"
      },
      {
        "icon": "blood2",
        "text": "吐血"
      },
      {
        "icon": "shy2",
        "text": "脸红"
      },
      {
        "icon": "angry",
        "text": "生气"
      },
      {
        "icon": "nomatter",
        "text": "无所谓"
      },
      {
        "icon": "dead",
        "text": "死翘翘"
      },
      {
        "icon": "insidious",
        "text": "阴险"
      },
      {
        "icon": "tongue",
        "text": "吐舌"
      }

    ]
  },
  "推特":{
    "type": "image",
    "name": "twemoji",
    "container":[
      {
        "icon": "smile",
        "text": "微笑"
      },
      {
        "icon": "tongue",
        "text": "吐舌"
      },
      {
        "icon": "tilted",
        "text": "歪头"
      },
      {
        "icon": "tiaomei",
        "text": "挑眉"
      },
      {
        "icon": "shy",
        "text": "害羞"
      },
      {
        "icon": "sweat",
        "text": "流汗"
      },
      {
        "icon": "proud",
        "text": "得意"
      },{
        "icon": "uncomfort",
        "text": "难受"
      },{
        "icon": "smilecry",
        "text": "笑哭"
      },
      {
        "icon": "love",
        "text": "喜欢"
      },{
        "icon": "notalk",
        "text": "不说话"
      },{
        "icon": "happy",
        "text": "开心"
      },{
        "icon": "frightened",
        "text": "惊恐"
      },{
        "icon": "dtongue",
        "text": "吐舌"
      },{
        "icon": "cry",
        "text": "哭泣"
      },{
        "icon": "cool",
        "text": "炫酷"
      },{
        "icon": "bigsmile",
        "text": "红脸笑"
      },{
        "icon": "ok",
        "text": "可以"
      },{
        "icon": "kiss",
        "text": "亲亲"
      },{
        "icon": "angry",
        "text": "生气"
      },{
        "icon": "family",
        "text": "家庭"
      },{
        "icon": "congratulate",
        "text": "祝贺"
      },{
        "icon": "gift",
        "text": "礼物"
      },{
        "icon": "prayer",
        "text": "祈祷"
      },{
        "icon": "star",
        "text": "星星"
      }
    ]
  }  
}

写在最后

没啥，上面太长，这是用来目录定位的…

ps.有好的，请推荐给我啊，顺便试试评论表情吧~

概述

Comment2Bark 是一款 Typecho 评论推送插件，核心功能是将博客评论通过 Bark 服务推送至 iOS 设备。本项目在原有代码基础上进行了全面重构，优化了代码结构、修复了兼容性问题、完善了功能实现。

技术背景：Bark 推送服务

Bark 是由 Finb 开发的开源 iOS 推送工具，采用 MIT 协议发布。其技术特点包括：

• 服务端通过标准 HTTP POST 请求触发推送
• 客户端支持 iOS 15.0+
• 支持自定义图标、分组、音效等参数
• 可部署私有服务器或使用官方托管服务

功能特性

推送场景

核心能力

• 🔗 精确链接 - 自动计算评论分页，点击推送直接跳转到对应评论位置
• 🔄 自动重试 - 推送失败自动重试 3 次（间隔 1s、2s、4s）
• 🛡️ 安全处理 - 评论内容经过 HTML 过滤和 XSS 处理
• 📊 调试模式 - 启用后可查看详细推送日志
• 🎨 自定义配置 - 支持自定义图标、分组、提示音

功能配置说明

推送数据格式

插件向 Bark API 发送的 POST 数据：

[
    'title'     => '📩 【博客名】有新评论',
    'body'      => '「文章标题」\n👤 评论者：内容摘要...',
    'url'       => 'https://example.com/article/comment-page-1#comment-123',
    'icon'      => $options->barkIcon,      // 可选
    'group'     => $options->barkGroup,     // 可选
    'isArchive' => $options->barkArchive,   // 1 或 0
    'sound'     => $options->barkSound,     // 可选
    'level'     => 'active' | 'timeSensitive'
]

安装与使用

环境要求

• Typecho 1.3.0
• PHP ≥ 7.4（推荐 8.0+）

安装步骤

1. 下载插件文件
2. 解压至 /usr/plugins/Comment2Bark/
3. 后台「控制台 → 插件」启用
4. 填写 Bark Key 完成配置

获取 Bark Key

1. iOS 设备安装 Bark App
2. 打开 App 自动生成 Key
3. 格式示例：https://api.day.app/xxxxxxxxxx

版本历史

v2.0.2

• ​代码优化​：match 表达式语法修正
• ​安全加强​：回复通知中原评论内容统一使用 sanitizeText 处理

v2.0.1

• ​钩子修复​：修复 onMark 钩子参数错误
• ​通知优化​：审核通知区分回复和新评论

v2.0.0

• ​代码重构​：精简代码，模块化设计
• ​钩子升级​：使用 finishComment 替代已弃用的 onComment
• ​链接修复​：修复 Typecho permalink 字段不存在问题，改用 Widget_Archive 动态获取
• ​分页优化​：修复评论分页计算逻辑，支持 ASC/DESC 两种排序方式
• ​统一架构​：5 个推送场景统一使用相同的链接构建逻辑

v1.4.0

• 全面代码重构，提取魔法数字为类常量
• 合并 barkSend 和 finishComment 为统一入口
• 新增 isSuccess()、sanitizeText() 等辅助方法
• 优化评论链接生成逻辑

v1.3.0

• 添加推送失败重试机制
• 加强评论内容处理，防止 XSS
• 添加推送分级参数

v1.2.0 - v1.2.1

• 支持 Typecho 1.3.0+ 版本
• 使用新的 finishComment 回调

v1.0

• 初始版本，实现基本评论推送功能

项目信息

• 开源协议：MIT
• 代码仓库：https://github.com/NoEggEgg/Comment2Bark
• Bark：https://github.com/Finb/Bark

相关资源

Typecho 插件开发文档：http://docs.typecho.org/plugins
Bark 服务端部署指南：https://bark.day.app/#/deploy
Bark 音效列表：https://github.com/Finb/Bark/tree/master/Sounds

前言

距离上次发布 v1.1 版本已经过去了三个月，Typecho 官方也发布了备受期待的 1.3.0 版本。这次大版本更新带来了许多底层架构的改进，但也导致了不少插件出现兼容性问题。

Typecho 又拍云文件管理插件修改版使用指南：新增自定义目录结构功能

昨天我更新了新版本遇到的问题：升级 Typecho 1.3.0 后，又拍云插件在后台文件管理页面报错，无法正常显示已有文件的 URL。于是更新了 UpyunFile v1.2 版本，这个版本不仅彻底解决了 Typecho 1.3.0 的兼容性问题，还进一步简化了配置流程，让插件使用更加便捷。

1、核心修复：Typecho 1.3.0 兼容性适配

问题现象

升级 Typecho 1.3.0 后，你可能会遇到以下问题：

• 后台文件管理页面报错：附件 URL 显示异常或页面报错

TypeError: UpyunFile_Plugin::attachmentHandle(): 
Argument #1 ($content) must be of type array, Typecho\Config given
...

• 文章中的附件链接失效：图片、文件无法正常加载

https://cdn.example.com/  ← 路径缺失！

解决方案

v1.2 版本采用了多重兼容策略，确保在不同 Typecho 版本下都能正常工作：

public static function attachmentHandle(Typecho\Config $content) {
    // 1. 优先检查新版本的 Config 对象结构
    if (isset($content->attachment) && isset($content->attachment->path)) {
        $path = $content->attachment->path;
    } 
    // 2. 其次检查直接 path 属性
    else if (isset($content->path)) {
        $path = $content->path;
    } 
    // 3. 最后尝试从 text 字段反序列化（兼容旧数据）
    else if (isset($content->text)) {
        $attachment = @unserialize($content->text);
        if (is_array($attachment) && isset($attachment['path'])) {
            $path = $attachment['path'];
        }
    }
    // 构建完整 URL
    return Typecho_Common::url($path, $domain);
}

2、资源泄漏修复

在代码审查中发现了一个潜在的资源管理问题：

修复前（存在资源泄漏风险）：

$fh = fopen($uploadfile, 'rb');
$upyun->write($path, $fh);
// 如果 write() 抛出异常，fclose 不会执行
if (is_resource($fh)) {
    fclose($fh);
}

修复后（确保资源释放）：

$fh = fopen($uploadfile, 'rb');
try {
    $upyun->write($path, $fh);
} finally {
    // 无论是否异常，都会执行
    if (is_resource($fh)) {
        fclose($fh);
    }
}

3、配置简化：移除目录结构选择

为什么要简化？

在 v1.1 版本中，我提供了三种目录结构模式：

1. 自定义结构 - /files/年/月/文件名
2. Typecho结构 - /typecho/usr/uploads/年/月/文件名
3. 精简结构 - /年/月/文件名

但在实际使用中，我发现：

• 90% 的用户只使用自定义结构
• 三种模式增加了代码复杂度
• 配置界面不够直观

新的设计

v1.2 版本移除了目录结构模式选择，只保留一个自定义路径输入框：

自定义路径：/files  （默认为 /files）

最终文件路径格式固定为：

{自定义路径}/{年}/{月}/{文件名}
例如：/files/2026/04/example.jpg

好处

• 🎨 界面更简洁 - 减少用户选择负担
• 🔧 配置更简单 - 只需填写一个路径
• 🚀 代码更精简 - 减少潜在 bug
• 📚 逻辑更清晰 - 统一的行为预期

📋 版本更新记录

v1.2 (2026-04-02)

🐛 修复

• 修复 Typecho 1.3.0 兼容性问题
• 修复后台文件管理 URL 不完整问题
• 修复文件句柄资源泄漏风险

✨ 优化

• 简化目录结构配置，移除模式选择
• 自定义路径默认值改为 /files
• 完善代码注释，提升可维护性

v1.1 (2026-01-09)

• ✅ 新增自定义目录结构功能
• ✅ 优化后台配置界面用户体验

🚀 安装与使用指南

系统要求

• Typecho 1.1+ 版本（推荐 1.3.0+）
• PHP 7.0+ 运行环境
• 有效的又拍云服务账号

升级步骤（从 v1.1 升级）

1. 备份数据 - 建议先备份数据库和现有插件配置
2. 下载新版本 - 获取 v1.2 版本插件包
3. 替换文件 - 覆盖原有插件文件（保留配置）
4. 检查配置 - 进入插件设置，确认自定义路径正确
5. 测试验证 - 上传测试文件，检查 URL 生成是否正常

或者你直接获取 GitHub 上 Plugin.php 的代码覆盖一下呗，😂

全新安装步骤

1. 下载插件压缩包

2. 解压至 Typecho 的 usr/plugins 目录，文件夹命名为 UpyunFile

3. 在 Typecho 后台「控制台」->「插件」中启用插件

4. 进入插件设置页面，配置以下参数：

   • 绑定域名 - 又拍云服务绑定的域名（如 https://cdn.example.com）
   • 自定义路径 - 文件上传路径（默认为 /files）
   • 服务名称 - 又拍云服务名称
   • 操作员 - 又拍云操作员账号
   • 密码 - 又拍云操作员密码

5. 保存设置，完成安装

⚙️ 配置详解

基本配置

高级配置（可选）

又拍云图片处理

需要在又拍云控制台创建缩略图版本，然后将版本名称填入插件配置。

• 缩略图版本名称 - 如 thumb、small 等
• 转码输出格式 - 如 jpg、png、webp

⚠️ 注意：带有 _nothumb 后缀的图片不会被处理（如 example_nothumb.png）

Token 防盗链

1. 在又拍云控制台启用 Token 防盗链功能
2. 将密钥填入插件配置
3. 设置签名过期时间（单位：秒）

📥 下载与反馈

项目地址

• GitHub Releases：https://github.com/NoEggEgg/UpyunFile

问题反馈

如果您在使用过程中遇到任何问题，欢迎通过以下方式反馈：

• 在 GitHub 提交 Issue
• 在本文评论区留言

参与贡献

欢迎提交 Pull Request 或提出改进建议！

🙏 致谢

• 原版插件：https://github.com/codesee/UpyunFile
• 二改版本：https://github.com/ShadowySpirits/UpyunFile
• 三改版本：https://github.com/liuran001/UpyunFile
• Typecho 官方：https://typecho.org
• 又拍云官方：https://www.upyun.com

最近有人反馈说，通过Feedly订阅我的博客总是失败。我自己在浏览器里打开wuqishi.com/feed/​明明一切正常，这典型的“RSS 403”问题，相当于关上了订阅的大门。折腾一圈下来，发现根源无非两个：服务器上的PHP乱输出，或者Cloudflare等CDN的“误杀” 。下面就把我的排查过程和解决方案贴出来，希望能帮你一把。

首先，我们得知道问题出在哪个环节。打开终端，用下面这条命令模拟一下RSS阅读器的请求：

curl -I -H "User-Agent: Feedly/1.0" https://wuqishi.com/feed/

重点看返回的HTTP状态码和响应头：

• ​如果状态码是403，并且响应头里带有 ​CF-RAY​​字段：那问题八成出在Cloudflare的WAF或者Bot防护规则上，你的请求在CDN边缘就被掐掉了。直接看下面关于Cloudflare的章节。
• ​如果状态码不是200，也没有 ​CF-RAY​​头：这是你的源站服务器（比如Nginx/PHP）自己返回的错误，去看PHP修复那部分。
• ​如果返回了XML，但内容最前面混入了PHP的Warning或Deprecated信息：这就是经典的“PHP输出污染”，XML格式被破坏，阅读器自然无法识别。解决方案也在PHP部分。

PHP层修复：搞定版本兼容性与错误输出

不同PHP版本，坑点不一样。这里我简单列一下，方便大家对号入座：

• ​PHP 7.4 / 8.0 / 8.1​：这几个版本比较安分，主要确保php.ini​里display_errors = Off别让警告输出就行。不过PHP 7.4已经停止官方支持了，能升级还是建议升级。
• ​PHP 8.2​：重点关注！ 这个版本开始默认弃用“动态属性”，很多老程序会因此抛出Deprecated​警告，这些警告会直接插在RSS的XML开头，导致解析失败。解决办法是在程序入口或php.ini里关掉错误显示。
• ​PHP 8.3 / 8.4：类型系统越来越严格。8.3对动态属性控制更狠，8.4则弃用了隐式可空类型声明。确保你用的博客程序（如Typecho, WordPress）已经发布了兼容这些新版本的更新。

​具体操作：

在你的网站入口文件（例如index.php​）最开头，或者直接在php.ini配置文件中，加入以下代码来压制错误输出：

// 方法一：在程序入口文件（如 index.php）顶部添加
error_reporting(0);
ini_set('display_errors', '0');

// 方法二：修改 php.ini（效果更全局）
display_errors = Off
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED

我的建议是，无论用哪个版本，在生产环境永远关闭 ​display_errors​​ 。 修改完配置后，​别忘了重启PHP-FPM服务​（例如 systemctl restart php8.2-fpm）。

Cloudflare层修复：让WAF规则放行你的订阅源

浏览器能打开，阅读器报403——这是Cloudflare把RSS阅读器的请求当成可疑机器人给拦了。我们需要调整它的安全规则。

第一步：关闭“Bot Fight Mode”

​操作路径：Cloudflare 控制台 → 安全性 (Security) → 自动程序 (Bots)

找到“自动程序攻击模式”(Bot Fight Mode)，​把它关掉。免费版的这个模式有点“宁杀错不放过”，会误伤很多正常的自动请求，比如RSS阅读器、搜索引擎爬虫。

如果你是Pro版用户，可以开启更智能的“Super Bot Fight Mode”，然后在“已验证的机器人”(Verified Bots)分类中，设置规则为“允许”(Allow)，这样Feedly、Googlebot这些正规军就能通行了。

第二步：配置精准的WAF规则

我们需要创建一条规则，专门放行RSS订阅地址的请求，不让后续的安防规则拦截它。

在Cloudflare控制台，进入​安全性 → WAF → 自定义规则，创建一个新规则：

1. ​规则名称：比如“Allow RSS Feed Subscribers”

2. ​规则表达式 (When incoming requests match…) ：

   (http.request.uri.path contains "/feed") or (http.request.uri.path contains "/rss") or (http.request.uri.path contains "/atom")
   

   （请根据你博客实际的RSS路径修改）

3. ​操作 (Then…) ​：选择 跳过 (Skip)

4. ​在Skip的子选项中，勾选“跳过所有剩余的自定义规则”(Skip remaining custom rules) 。这一步非常关键，确保RSS请求不受其他可能存在的拦截规则影响。

然后，把这个规则的​优先级拖到比较靠前的位置，确保它先于其他可能的拦截规则生效。

第三步：清除缓存

修改完任何Cloudflare设置后，一个好习惯是清除缓存。

​操作路径：Cloudflare 控制台 → 缓存 (Caching) → 配置 (Configuration) → 清除所有内容 (Purge Everything)。

点“清除所有”。之后，再用阅读器或curl命令测试一下你的RSS地址，应该就能正常返回了。

源站加固：Nginx配置兜底

为了防止有人绕过Cloudflare直接攻击源站，或者作为你没用CDN时的防护，可以在Nginx里加一层基础防护。

把下面这段配置加到你的网站Nginx配置文件中（通常是 server块内）：

location ~ ^/(feed|rss|atom) {
    # 只允许GET请求访问RSS
    limit_except GET { deny all; }
    
    # 拦截一些常见的恶意扫描工具的UA
    if ($http_user_agent ~* (sqlmap|nikto|nmap|zgrab|gobuster)) {
        return 444;
    }
    
    # 设置访问频率限制，防止被刷
    limit_req zone=one burst=5 nodelay;
    
    # 这里是你的原始PHP处理逻辑，保持不变
    try_files $uri $uri/ /index.php?$args;
}

# 可以顺便拦一下其他常见恶意请求路径
location ~* /(wp-admin|xmlrpc\.php|\.env|\.git) {
    return 444;
}

记得根据你服务器的实际情况，调整频率限制区域(zone​)的名称和limit_req​的参数。配置好后，运行 nginx -t​测试配置，然后 systemctl reload nginx重载生效。

验证清单

都配置完之后，可以用下面这个清单快速检查一下是否全部生效：

1. ​检查PHP输出：直接用浏览器打开你的RSS订阅地址，查看网页源代码，看最前面有没有不该出现的PHP错误信息。
2. ​模拟阅读器请求​：在终端运行 curl -H "User-Agent: Feedly/1.0" https://你的域名.com/feed，确认返回状态码是200，并且内容是干净的XML。
3. ​清理Cloudflare缓存：在Cloudflare控制台的“缓存”设置里，执行“清除所有”的操作，确保新规则立即生效。
4. ​终极验证​：去 W3C Feed验证服务或你的Feedly订阅器里，重新添加一遍订阅链接，看看是否成功。

按照上面步骤走一遍，绝大多数RSS 403的问题都能解决。如果还有问题，欢迎在评论区留言讨论。

文章有点长，用AI总结了核心摘要：

网站被镜像怎么解决？从发现网站被镜像、反镜像技术防护到DMCA投诉下架，提供2026年4月最新完整解决方案，含Nginx拦截代码、JS自动跳转脚本、服务器日志分析方法、中英双语投诉邮件模板。

关键词：网站被镜像 | 反镜像 | DMCA投诉 | Nginx防护 | JS跳转

最近不止一次发现圈里不少博主的站和我之前一样，都遭遇了一件挺膈应人的事：网站被镜像。

简单说，就是有人用技术手段，把你的博客整个"复印"到他的域名下，实时同步。你更新一篇文章，它那边几分钟后也出现一篇繁体（或简体）版。他靠你的内容吸引流量、放广告赚钱，甚至用你的"信誉"给他的垃圾站刷权重。

这种感觉，就像自己家被装了个单向镜，有人在另一面观察和复制你的一切。经过一番研究和实战，我整理出这份从侦查、防御到反击的完整指南，希望能帮到同样困扰的你。

一、什么是网站被镜像？为什么必须处理？

网站被镜像（Site Mirroring）是指第三方通过技术手段实时复制你的网站全部内容，部署在其域名下。常见危害：

⚠️ 关键提醒：2025年后Google对"重复内容"的判定更严格，镜像站若采用繁体转换、同义词替换等"伪原创"手段，你的原站反而可能被误判为抄袭者。必须主动举证投诉。

二、如何发现网站被镜像（3种方法）

方法一：搜索引擎指纹检测（适合所有人）

操作步骤：

1. 从你的文章中提取唯一性句子（含个人经历、特定数据、独特观点）
2. 在Google搜索框输入："唯一句子"（带双引号精确匹配）
3. 查看搜索结果中是否有非你域名的相同内容

示例：

搜索："2023年我在阳台用M1 Mac调试Nginx时发现的444状态码特性"
结果：若出现 你的域名以外的域名，即为镜像站

进阶搜索指令：

方法二：服务器日志分析（技术人必备）

查看Nginx访问日志（通常位于 /var/log/nginx/access.log 或 /var/log/nginx/access.log.1）：

识别特征A：爬虫式高频请求

# 危险信号：同一IP短时间内顺序抓取全站
203.0.113.45 - - [01/Apr/2026:09:15:01 +0800] "GET /" 200 1024 "-" "python-requests/2.28.1"
203.0.113.45 - - [01/Apr/2026:09:15:02 +0800] "GET /post-1" 200 2048 "-" "python-requests/2.28.1"
203.0.113.45 - - [01/Apr/2026:09:15:03 +0800] "GET /post-2" 200 2048 "-" "python-requests/2.28.1"
# ↑ 1分钟内顺序请求首页+文章页，UA为爬虫工具 = 99%是镜像程序

快速筛选命令：

# 找出高频访问IP（1分钟内超过20次）
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# 筛选特定UA的日志
grep -i "python-requests\|curl\|wget" /var/log/nginx/access.log

识别特征B：伪造Googlebot（最常见）

双重DNS验证法（100%准确，必须两步都做）：

# 第1步：反向DNS查询IP（确认域名归属）
$ host 66.249.90.77
66.249.90.77.in-addr.arpa domain name pointer rate-limited-proxy-66-249-90-77.googlebot.com.
# ✅ 正确结果：以.googlebot.com、.googleusercontent.com或.google.com结尾

# 第2步：正向DNS验证域名（关键！防止"反向伪造"）
$ host rate-limited-proxy-66-249-90-77.googlebot.com.
rate-limited-proxy-66-249-90-77.googlebot.com has address 66.249.90.77
# ✅ 必须返回原IP 66.249.90.77

判定标准：

📌 2026年4月最新：Googlebot IP段持续扩展，新增34.104.x.x、34.118.x.x等范围。硬编码IP拦截已不可靠，强烈建议使用官方JSON动态验证：https://developers.google.com/static/search/apis/ipranges/googlebot.json

识别特征C：Referer暴露盗链

# 日志中搜索静态资源请求，查看第11个字段（Referer）
66.249.xx.xx - - [01/Apr/2026:09:20:15 +0800] "GET /wp-content/uploads/photo.jpg" 200 51234 "https://可疑镜像站.com/文章页" "Mozilla/5.0..."
# 字段分解：IP - 用户 - 时间 "请求" 状态码 字节数 "Referer" "User-Agent"
#                                                                 ↑ 看这个Referer！

快速筛选盗链：

# 找出非本域名的图片请求Referer
awk '$11 !~ /wuqishi.com|"-"|""/ && /GET.*\.(jpg|png|gif)/ {print $11}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

方法三：主动钓鱼陷阱（100%实锤）

原理：创建无任何入口的秘密页面，镜像站通过爬虫抓取后必然复制，即可证明实时镜像关系。

操作步骤：

步骤1：创建诱饵页面（5分钟）
├── 路径：/mirror-trap-2026-[随机8位字符串].html
│   示例：/mirror-trap-2026-a3k9m2p7.html
├── 内容：必须包含唯一识别文本
│   <p>此页面用于检测镜像站，唯一ID: XJ9K2M-A3K9M2P7，时间戳: 2026-04-01T09:54:00+08:00</p>
│   <p>作者：wuqishi，来源：https://wuqishi.com</p>
├── 关键操作：
│   × 不放入任何导航菜单
│   × 不添加到Sitemap.xml
│   × 不从任何页面链接引用
│   × 不提交到搜索引擎
│
步骤2：等待24-48小时（给爬虫抓取时间）
│
步骤3：搜索引擎验证（实锤证据）
├── Google搜索：site:可疑域名.com "XJ9K2M-A3K9M2P7"
├── Bing搜索：site:可疑域名.com "wuqishi"
└── 若出现结果 = 实时镜像实锤证据，立即截图保存（含时间戳）

证据保全清单：

• 钓鱼页面源代码截图（显示创建时间）
• 搜索引擎结果截图（显示镜像站URL和抓取时间）
• 两站页面对比截图（并排显示相同内容）
• 服务器日志（显示可疑IP的抓取记录）

三、反镜像技术防护方案

方案A：Nginx层拦截伪造爬虫

用途：拦截伪造Googlebot的镜像爬虫 | 适用：Nginx 1.18+ | 注意：IP段需定期更新，建议结合DNS验证

# ============================================
# Nginx 反镜像拦截配置
# 位置：/etc/nginx/conf.d/anti-mirror.conf 或站点配置
# 生效命令：sudo nginx -t && sudo systemctl reload nginx
# ============================================

# 第1步：定义真假Googlebot判断映射（http块内）
map $http_user_agent $is_googlebot {
    ~*googlebot 1;
    default 0;
}

# 第2步：server块内添加拦截规则
server {
    listen 80;
    listen [::]:80;
    server_name wuqishi.com www.wuqishi.com;
  
    # 拦截假Googlebot（IP不在官方段）
    if ($is_googlebot = 1) {
        # 2026年4月已知Googlebot IPv4段（需定期核对）
        # 66.249.x.x, 64.233.x.x, 192.178.x.x, 34.100.x.x, 34.101.x.x, 34.104.x.x, 34.118.x.x
        if ($remote_addr !~* "^(66\.249\.|64\.233\.|192\.178\.|34\.100\.|34\.101\.|34\.104\.|34\.118\.)") {
            return 444;  # Nginx立即断开，不返回任何数据
        }
    }
  
    # 拦截常见爬虫UA（镜像程序常用）
    if ($http_user_agent ~* "(python-requests|curl/|wget/|scrapy|httpx|aiohttp|libwww-perl)") {
        return 444;
    }
  
    # 拦截空UA或可疑UA（可选，视情况启用）
    # if ($http_user_agent = "" || $http_user_agent = "-") {
    #     return 444;
    # }
  
    # 正常location配置...
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

🔧 444状态码详解：Nginx特有非标准状态码，立即关闭TCP连接，不发送HTTP头/体，不消耗带宽。客户端表现为"连接被重置"或"空响应"，仅在Nginx日志中记录。比403更节省资源，且不给爬虫任何反馈。

验证配置生效：

# 测试假Googlebot是否被拦截（应返回空响应）
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     -H "X-Forwarded-For: 1.2.3.4" \
     https://wuqishi.com/test
# 预期结果：curl: (52) Empty reply from server（空回复）

# 查看Nginx日志确认
sudo tail -f /var/log/nginx/access.log
# 预期记录：1.2.3.4 - - [时间] "GET /test" 444 0 "-" "假Googlebot UA"

方案B：前端JS自动跳转（终极反镜像方案）

用途：检测域名，非法访问则强制跳转回本站 | SEO价值：搜索引擎爬虫不执行JS，不影响收录；真实用户访问镜像站时跳转回主站，增加主站流量权重

代码优势：

• ✅ Base64+反转混淆，防止对方批量删除
• ✅ 清空页面内容，阻止镜像站展示
• ✅ 延迟跳转，确保警告弹窗显示
• ✅ 支持多级子域名白名单
• ✅ 错误静默处理，不影响正常访问

生成你的专属编码（必须执行，不能用示例）：

// 在浏览器F12控制台执行，替换为你的域名
btoa('你的域名'.split('').reverse().join(''))

// 示例执行过程：
// 1. 'wuqishi.com'.split('').reverse().join('') → 'moc.ihsiquw'
// 2. btoa('moc.ihsiquw') → 'bW9jLmlic2lxdXc='
// 最终结果：'bW9jLmlic2lxdXc='（仅适用于wuqishi.com）

完整可用代码（必须替换encodedHost值）：

<!-- 放置于主题header.php的<head>最顶部，确保最先执行 -->
<script>
/**
 * 反镜像防御脚本 v1.1
 * 功能：检测域名，非法访问则跳转回正版站点
 * SEO友好：搜索引擎爬虫不执行JS；真实用户跳转回主站，增加流量权重
 * 兼容性：Chrome/Firefox/Safari/Edge/IE9+
 */
(function() {
    'use strict';
  
    // ==================== 配置区（必须修改） ====================
    var CONFIG = {
        // 【重要】替换为你的域名编码：btoa('你的域名'.split('').reverse().join(''))
        // 示例'wuqishi.com' → 'bW9jLmlic2lxdXc='（仅作参考，必须重新生成）
        encodedHost: '【在此处粘贴你的编码】',
  
        // 允许的子域名（按需增删）
        allowedSubdomains: ['www', 'blog', 'cdn', 'img', 'static'],
  
        // 跳转延迟（毫秒，确保alert先显示）
        redirectDelay: 200,
  
        // 是否显示警告弹窗（true/false）
        showAlert: true,
  
        // 跳转后是否携带原路径和参数
        keepPath: true,
        keepSearch: true,
        keepHash: false  // 锚点通常不需要
    };
  
    // ==================== 核心逻辑（无需修改） ====================
    try {
        // 解码真实域名：Base64解码 → 字符串反转 → 原文
        var realHost = atob(CONFIG.encodedHost).split('').reverse().join('');
        var currentHost = window.location.hostname.toLowerCase();
  
        // 域名白名单检查
        var isValid = false;
        var checkList = [realHost, 'www.' + realHost];
  
        // 添加配置的子域名
        if (CONFIG.allowedSubdomains && CONFIG.allowedSubdomains.length > 0) {
            CONFIG.allowedSubdomains.forEach(function(sub) {
                if (sub) checkList.push(sub.toLowerCase() + '.' + realHost);
            });
        }
  
        // 检查完全匹配
        for (var i = 0; i < checkList.length; i++) {
            if (currentHost === checkList[i]) {
                isValid = true;
                break;
            }
        }
  
        // 检查多级子域名（如 blog.cdn.wuqishi.com）
        if (!isValid && currentHost.indexOf('.' + realHost) > -1) {
            isValid = true;
        }
  
        // 非法访问处理
        if (!isValid) {
            // 立即停止页面解析
            if (window.stop) {
                window.stop();
            } else if (document.execCommand) {
                document.execCommand('Stop'); // IE9-10兼容
            }
      
            // 清空页面内容（防止镜像站内容显示）
            if (document.body) document.body.innerHTML = '';
            if (document.documentElement) document.documentElement.innerHTML = '';
      
            // 构建跳转URL
            var targetUrl = 'https://' + realHost;
            if (CONFIG.keepPath) {
                targetUrl += window.location.pathname || '';
            }
            if (CONFIG.keepSearch && window.location.search) {
                targetUrl += window.location.search;
            }
            if (CONFIG.keepHash && window.location.hash) {
                targetUrl += window.location.hash;
            }
      
            // 显示警告（可选）
            if (CONFIG.showAlert && window.alert) {
                try {
                    window.alert('⚠️ 安全警告\n\n您正在访问盗版镜像网站，内容可能已被篡改或植入恶意代码！\n\n即将跳转至正版网站：' + realHost);
                } catch(e) {}
            }
      
            // 延迟跳转
            setTimeout(function() {
                if (window.location.replace) {
                    window.location.replace(targetUrl);  // replace不保留历史记录
                } else {
                    window.location.href = targetUrl;    // 兼容旧浏览器
                }
            }, CONFIG.redirectDelay);
      
            // 控制台日志（调试用）
            if (window.console && console.warn) {
                console.warn('[AntiMirror] 已拦截非法访问: ' + currentHost + ' → ' + realHost);
            }
        }
    } catch(e) {
        // 任何错误静默处理，确保不影响正常访问
        if (window.console && console.error) {
            console.error('[AntiMirror] 脚本错误（已忽略）:', e.message);
        }
    }
})();
</script>

测试验证步骤：

1. 将代码保存为本地HTML文件
2. 修改encodedHost为任意错误值（如'xxxxxx'）
3. 用浏览器打开，应触发跳转或显示警告
4. 恢复正确编码，部署到生产环境

💡 维护建议：每3-6个月更换一次编码方式，或升级混淆算法（如RC4轻量加密），防止攻击者批量破解。

方案C：图片/资源防盗链

用途：防止镜像站盗用图片流量，保护图片SEO搜索流量

# ============================================
# Nginx 图片防盗链配置
# 位置：/etc/nginx/conf.d/anti-leech.conf
# ============================================

# 图片及静态资源防盗链
location ~* \.(jpg|jpeg|png|gif|webp|bmp|svg|ico|css|js|woff|woff2|ttf|eot)$ {
    # 允许的Referer来源：
    # none = 无Referer（直接访问图片）
    # blocked = 被防火墙删除Referer的请求
    # server_names = 当前server_name
    # ~\.wuqishi\.com = 匹配wuqishi.com及所有子域名
    # ~\.google\. = 允许Google图片搜索
    valid_referers none blocked server_names 
                     ~\.wuqishi\.com 
                     ~\.google\. 
                     ~\.bing\. 
                     ~\.baidu\. 
                     ~\.duckduckgo\.;
  
    # 非法Referer处理
    if ($invalid_referer) {
        # 方案1：返回403（推荐，利于SEO识别）
        return 403;
  
        # 方案2：返回自定义"禁止盗链"图片（取消注释使用）
        # rewrite ^ /images/anti-leech.png break;
  
        # 方案3：返回302重定向到警告页面（取消注释使用）
        # return 302 https://wuqishi.com/anti-leech-warning.html;
    }
  
    # 安全响应头
    add_header X-Content-Type-Options "nosniff";
    add_header X-Frame-Options "SAMEORIGIN";
  
    # SEO优化：缓存控制
    expires 6M;  # 6个月
    add_header Cache-Control "public, immutable";
}

# 盗链日志记录（用于投诉证据）
location ~* \.(jpg|jpeg|png|gif|webp)$ {
    valid_referers none blocked server_names ~\.wuqishi\.com;
  
    if ($invalid_referer) {
        # 记录到专用日志（投诉时作为证据）
        access_log /var/log/nginx/anti-leech.log detailed;
        return 403;
    }
  
    # 正常请求记录到标准日志
    access_log /var/log/nginx/access.log;
}

查看盗链日志：

# 实时查看盗链记录
sudo tail -f /var/log/nginx/anti-leech.log

# 统计盗链最多的域名
awk -F'"' '/http/ {print $4}' /var/log/nginx/anti-leech.log | sort | uniq -c | sort -rn | head -10

四、移除镜像站（平台投诉）

向搜索引擎投诉（恢复排名）

关键区别：

• Removals Tool：只能移除你拥有的网站（需验证所有权）
• Outdated Content：处理你不拥有的网站的特定URL
• Legal Removals：正式法律投诉，效力最强但流程最长

百度投诉：

• 使用 百度站长平台 死链提交（仅自己站点）
• 镜像站侵权向 互联网信息服务投诉平台 举报

向主机商/域名注册商投诉（直接拔线）

查询镜像站信息：

# 命令行查询
whois 镜像域名.com

# 在线工具（更直观）
# https://who.is/
# https://www.whois.com/whois/

关键信息提取：

投诉效果排序：主机商（Hosting）> 注册商（Registrar）> CDN服务商（如Cloudflare）

向广告联盟举报（断其财路）

五、紧急行动清单（发现镜像后24小时内）

六、常见问题（FAQ）

Q1：镜像站用了繁体转换，Google会认为是不同内容吗？

不会。2025年后Google的多语言处理能力已能识别简繁体转换。但"同义词替换+段落重组"的"深度伪原创"可能骗过算法。建议主动提交DMCA投诉，人工审核更准确。

Q2：JS跳转会影响我的SEO吗？

不会。搜索引擎爬虫不执行JS，不会触发跳转。真实用户访问镜像站时跳转回你的站点，反而增加原站流量和停留时间，对SEO有利。

Q3：Nginx 444状态码会留下日志证据吗？

会。Nginx的access.log会记录444状态码，可用于向主机商证明对方爬虫被拦截的频率和规模。查看命令：grep ' 444 ' /var/log/nginx/access.log

Q4：投诉后多久能下架镜像站？

主机商DMCA通常24-72小时，Cloudflare转发3-7天，搜索引擎移除数天至数周。建议多渠道同时投诉，并在48小时后跟进。

Q5：镜像站换了新域名怎么办？

这是持久战。保存所有证据模板，新域名出现时快速套用。同时升级技术防御（如更换JS混淆方式），提高对方镜像成本。

Q6：我没有服务器权限，只能用CDN/虚拟主机怎么办？

重点使用前端JS防护（方案B），并在CDN层面设置Referer防盗链（如Cloudflare的Scrape Shield）。同时加大投诉力度。

七、2026年新增威胁：AI爬虫镜像

ChatGPT-5、Claude-4、Perplexity等AI服务开始大规模抓取网页内容用于训练，部分被滥用为实时镜像源。

特征识别：

防护升级（可选，视内容策略）：

# 拦截AI爬虫（可能误伤合法AI搜索，请谨慎使用）
if ($http_user_agent ~* "(GPTBot|ClaudeBot|Anthropic|PerplexityBot|CCBot|FacebookBot)") {
    # 方案1：完全拦截
    # return 403;
  
    # 方案2：限速（保留服务但降低频率）
    limit_req zone=ai_limit burst=5 nodelay;
}

# 或在robots.txt中限制（依赖对方遵守）
# User-agent: GPTBot
# Disallow: /

💡 建议：对AI爬虫采取区分策略。允许合法AI搜索（如Bing Chat）但限制纯训练抓取，或要求遵守robots.txt并标注来源。

附录：DMCA投诉邮件模板（中英双语）

⚖️ 法律免责声明：本文提供的技术方法仅供合法防御使用。使用DMCA投诉等法律手段时，请确保你拥有相关内容的完整版权。技术拦截手段请确保不误伤真实用户和合法搜索引擎爬虫。

Subject: DMCA Takedown Notice - Copyright Infringement on [Mirror Domain]

To: [Hosting Provider Abuse Department] <abuse@[hosting-provider].com>
Cc: [Your Email] (for records)
Date: [Date]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. CONTACT INFORMATION
   Name: [Your Full Name]
   Email: [Your Email Address]
   Phone: [Your Phone Number]
   Physical Address: [Your Address]
   Website: wuqishi.com

2. COPYRIGHTED WORK DESCRIPTION
   I am the copyright owner of the following original content:
   
   Original URLs on my website:
   • https://wuqishi.com/original-article-1 (Published: [Date])
   • https://wuqishi.com/original-article-2 (Published: [Date])
   • https://wuqishi.com/original-article-3 (Published: [Date])
   (Full list available upon request)

3. INFRINGING MATERIAL IDENTIFICATION
   The unauthorized copies are located at:
   
   Infringing URLs on the mirror site:
   • https://[mirror-domain]/copied-article-1
   • https://[mirror-domain]/copied-article-2
   • https://[mirror-domain]/copied-article-3
   (Corresponding to original URLs above)

4. TECHNICAL EVIDENCE OF MIRRORING
   The infringing website employs real-time mirroring technology to 
   replicate my entire website wuqishi.com:
   
   • Real-time synchronization: Honeypot test page (/secret-test-20260401) 
     created at [Date/Time UTC] appeared on their site at [Date/Time UTC] 
     (within 5 minutes of publication)
   • Content fingerprint: Unique string "wuqishi-verification-XJ9K2M" 
     appears identically on both sites
   • Server logs: IP [203.0.113.45] shows automated crawling patterns 
     from [Timestamp] to [Timestamp], 120 requests/minute
   • Identical structure: All articles, images, CSS, and JavaScript 
     are 1:1 copies, with internal links still pointing to wuqishi.com

5. GOOD FAITH BELIEF STATEMENT
   I have a good faith belief that the use of the copyrighted materials 
   described above is not authorized by the copyright owner, its agent, 
   or the law.

6. ACCURACY STATEMENT
   I swear, under penalty of perjury, that the information in this 
   notification is accurate and that I am the copyright owner or am 
   authorized to act on behalf of the owner of an exclusive right that 
   is allegedly infringed.

7. ELECTRONIC SIGNATURE
   /s/ [Your Full Name]
   Date: [Date]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ATTACHMENTS CHECKLIST:
□ [ ] Screenshot comparison: original vs. mirror site (side-by-side)
□ [ ] Server logs showing automated crawling (with timestamps)
□ [ ] Honeypot test page synchronization evidence
□ [ ] WHOIS lookup showing your company as hosting provider
□ [ ] Previous communication attempts (if any)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Please confirm receipt of this notice and advise on expected resolution 
timeline. I am prepared to provide additional evidence if required, 
including full server logs and forensic analysis.

Sincerely,
[Your Full Name]
[Your Title/Position]
wuqishi.com

主题：DMCA侵权下架通知 - [镜像域名] 版权侵权投诉

致：[主机商滥用投诉部门] <abuse@[主机商].com>
抄送：[你的邮箱]（备份）
日期：[日期]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 投诉人联系信息
   姓名：[你的全名]
   邮箱：[你的邮箱地址]
   电话：[你的电话号码]
   联系地址：[你的地址]
   网站：wuqishi.com

2. 被侵权作品描述
   我是以下原创内容的版权所有者：
   
   我网站上的原创链接：
   • https://wuqishi.com/原创文章-1（发布于：[日期]）
   • https://wuqishi.com/原创文章-2（发布于：[日期]）
   • https://wuqishi.com/原创文章-3（发布于：[日期]）
   （完整清单可根据要求提供）

3. 侵权内容识别
   未经授权的复制内容位于以下网址：
   
   镜像站上的侵权链接：
   • https://[镜像域名]/复制文章-1
   • https://[镜像域名]/复制文章-2
   • https://[镜像域名]/复制文章-3
   （与上方原创链接对应）

4. 镜像技术证据
   该侵权网站使用实时镜像技术复制我的整个网站 wuqishi.com：
   
   • 实时同步：钓鱼测试页面（/secret-test-20260401）于[UTC日期/时间]创建，
     于[UTC日期/时间]出现在对方网站（发布后5分钟内）
   • 内容指纹：唯一字符串"wuqishi-verification-XJ9K2M"在两站完全一致出现
   • 服务器日志：IP [203.0.113.45] 于[时间戳]至[时间戳]显示自动抓取模式，
     每分钟120次请求
   • 结构一致：所有文章、图片、CSS、JavaScript均为1:1复制，
     内部链接仍指向 wuqishi.com

5. 善意声明
   本人善意相信上述材料的使用未经版权所有者、其代理人或法律授权。

6. 准确性声明
   本人在伪证罪处罚的宣誓下声明，本通知中的信息准确无误，本人是
   版权所有者或经授权代表涉嫌被侵权的专有权的所有者行事。

7. 电子签名
   /s/ [你的全名]
   日期：[日期]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

附件检查清单：
□ [ ] 原创与镜像站对比截图（并排显示）
□ [ ] 显示自动抓取的服务器日志（含时间戳）
□ [ ] 钓鱼测试页面同步证据
□ [ ] 显示贵司为主机商的WHOIS查询结果
□ [ ] 之前与对方沟通的尝试记录（如有）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

请确认收到本通知并告知预计处理时间。如需补充证据（包括完整服务器日志
和取证分析），本人随时配合。

此致
[你的全名]
[你的职位/头衔]
wuqishi.com

Subject: AdSense Policy Violation Report - Copyright Infringement / Content Mirroring

To: Google AdSense Policy Team
Via: https://support.google.com/adsense/contact/violation_report

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

REPORTER INFORMATION

Name: [Your Full Name]
Email: [Your Email Address]
Website: wuqishi.com
Relationship to Site: Copyright Owner

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

VIOLATING PUBLISHER INFORMATION

Domain: [mirror-domain.com]
AdSense Publisher ID: [if visible in page source: ca-pub-XXXXXXXXXXXXXXXX]
Violation Type: Copyright Infringement (Content Mirroring / Scraping)
Date Discovered: [Date]
Estimated Revenue Impact: [if calculable]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

VIOLATION DETAILS

The website [mirror-domain.com] is displaying Google AdSense advertisements 
on content that has been illegally mirrored from my original website 
wuqishi.com through automated real-time replication.

TECHNICAL EVIDENCE:

1. Real-Time Mirroring Mechanism
   - Created honeypot page: wuqishi.com/secret-test-[timestamp]
     at [Date/Time UTC]
   - Detected on mirror site: [mirror-domain]/secret-test-[timestamp]
     at [Date/Time UTC] (4 minutes 32 seconds later)
   - Unique content fingerprint: "wuqishi-fingerprint-[id]" appears 
     identically on both sites (see screenshot)

2. Content Identity Verification
   - All articles, formatting, images, and HTML structure are 1:1 copies
   - CSS and JavaScript files served from my CDN (cdn.wuqishi.com) 
     with my domain in paths
   - Internal links remain pointing to wuqishi.com (revealing source)
   - Publication timestamps on mirror site match my original posts 
     within minutes

3. Automated Crawling Evidence
   - Server logs: Systematic requests from IP [203.0.113.45]
   - Time range: [Start Time] to [End Time] (UTC)
   - Pattern: Sequential requests to /, /post-1, /post-2... at 
     2-second intervals
   - User-Agent rotation: python-requests/2.28.1, fake Googlebot, 
     and generic Mozilla
   - Peak frequency: 120 requests/minute

AFFECTED ORIGINAL CONTENT (Sample):

My Original URLs:
• https://wuqishi.com/article/[slug-1] - Published [Date], Word Count: 2,400
• https://wuqishi.com/article/[slug-2] - Published [Date], Word Count: 1,800
• https://wuqishi.com/article/[slug-3] - Published [Date], Word Count: 3,200

Infringing Copies:
• https://[mirror-domain]/article/[slug-1] - Ad unit visible: [ca-pub-XXX]
• https://[mirror-domain]/article/[slug-2] - Ad unit visible: [ca-pub-XXX]
• https://[mirror-domain]/article/[slug-3] - Ad unit visible: [ca-pub-XXX]

AD PLACEMENT EVIDENCE:
• Screenshot 1: [mirror-domain]/article/[slug-1] with AdSense banner
  Ad position: Above article title
  Ad size: 728x90
• Screenshot 2: [mirror-domain]/article/[slug-2] with AdSense in-article ad
  Ad position: Mid-article
  Ad size: 300x250

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PREVIOUS ACTIONS TAKEN

[ ] Attempted direct contact with site operator: [details if applicable]
[x] Filed DMCA with hosting provider [Hosting Name]: [date], [reference #]
[ ] Other: [details]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

REQUESTED ACTION

I respectfully request that Google AdSense:

1. Immediately cease ad serving to [mirror-domain.com] and all associated 
   subdomains
2. Suspend or terminate the publisher account associated with this domain
3. Review any related accounts that may be operated by the same entity 
   (common patterns: [pattern details])
4. Withhold any pending payments for traffic generated from infringed content

This publisher is systematically generating revenue through unauthorized 
use of my intellectual property, violating AdSense Program Policies 
regarding:
- Copyrighted material (Section "Copyrighted material")
- Scraped content (Section "Scraped content")
- Misleading site behavior (Section "Misleading site behavior")

The scale of infringement (estimated [X] articles copied) and the 
technical sophistication (real-time mirroring) suggest this is not 
an isolated incident but a deliberate business model built on content 
theft.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DECLARATION

I have a good faith belief that the use of my copyrighted materials as 
described above is not authorized by me, my agent, or the law. The 
information in this notification is accurate, and under penalty of 
perjury, I am authorized to act on behalf of the owner of an exclusive 
right that is allegedly infringed.

/s/ [Your Full Name]
Date: [Date]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ATTACHMENTS (Total: [X] files):
□ Side-by-side content comparison screenshots (3 articles)
□ Honeypot page synchronization timestamps with server logs
□ Server logs showing automated crawling (IP [203.0.113.45])
□ Ad placement screenshots with visible ad unit IDs
□ WHOIS lookup for domain ownership verification
□ Traceroute showing hosting infrastructure

主题：AdSense政策违规举报 - 版权侵权/内容镜像

致：Google AdSense政策团队
通过：https://support.google.com/adsense/contact/violation_report

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

举报人信息

姓名：[你的全名]
邮箱：[你的邮箱地址]
网站：wuqishi.com
与网站关系：版权所有者

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

违规发布商信息

域名：[镜像域名]
AdSense发布商ID：[如页面源代码中可见：ca-pub-XXXXXXXXXXXXXXXX]
违规类型：版权侵权（内容镜像/抓取）
发现日期：[日期]
预估收入影响：[如可计算]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

违规详情

网站 [镜像域名] 通过自动实时复制技术，从我原创网站 wuqishi.com 
非法镜像内容，并在这些页面上投放Google AdSense广告获利。

技术证据：

1. 实时镜像机制
   - 创建钓鱼页面：wuqishi.com/secret-test-[时间戳]
     时间：[UTC日期/时间]
   - 在镜像站检测到：[镜像域名]/secret-test-[时间戳]
     时间：[UTC日期/时间]（4分32秒后）
   - 唯一内容指纹："wuqishi-fingerprint-[id]" 在两站完全一致出现
     （见截图）

2. 内容一致性验证
   - 所有文章、排版、图片和HTML结构均为1:1复制
   - CSS和JavaScript文件从我的CDN（cdn.wuqishi.com）加载，
     路径中包含我的域名
   - 内部链接仍指向 wuqishi.com（暴露来源）
   - 镜像站发布时间与我的原创文章相差仅数分钟

3. 自动抓取证据
   - 服务器日志：来自IP [203.0.113.45] 的系统性请求
   - 时间范围：[开始时间] 至 [结束时间]（UTC）
   - 模式：顺序请求 /、/post-1、/post-2...，间隔2秒
   - User-Agent轮换：python-requests/2.28.1、伪造Googlebot、
     通用Mozilla
   - 峰值频率：每分钟120次请求

受影响的原创内容（样本）：

我的原创链接：
• https://wuqishi.com/article/[文章别名-1] - 发布于[日期]，字数：2,400
• https://wuqishi.com/article/[文章别名-2] - 发布于[日期]，字数：1,800
• https://wuqishi.com/article/[文章别名-3] - 发布于[日期]，字数：3,200

侵权复制链接：
• https://[镜像域名]/article/[文章别名-1] - 可见广告单元：[ca-pub-XXX]
• https://[镜像域名]/article/[文章别名-2] - 可见广告单元：[ca-pub-XXX]
• https://[镜像域名]/article/[文章别名-3] - 可见广告单元：[ca-pub-XXX]

广告展示证据：
• 截图1：[镜像域名]/article/[文章别名-1] 含AdSense横幅广告
  广告位置：文章标题上方
  广告尺寸：728x90
• 截图2：[镜像域名]/article/[文章别名-2] 含AdSense文章内广告
  广告位置：文章中部
  广告尺寸：300x250

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

已采取的行动

[ ] 尝试直接联系网站运营者：[详情如有]
[x] 向主机商 [主机商名称] 提交DMCA投诉：[日期]，[参考编号]
[ ] 其他：[详情]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

请求采取的行动

本人恳请Google AdSense：

1. 立即停止向 [镜像域名] 及其所有子域名提供广告服务
2. 暂停或终止与该域名关联的发布商账户
3. 审查可能由同一实体运营的相关账户（共同特征：[特征详情]）
4. 扣留通过侵权内容产生的流量所对应的待结算款项

该发布商通过系统性未经授权使用我的知识产权获利，违反了
AdSense计划政策中关于：
- 版权材料（"Copyrighted material"章节）
- 抓取内容（"Scraped content"章节）
- 误导性网站行为（"Misleading site behavior"章节）

侵权规模（预估[X]篇文章被复制）和技术 sophistication（实时镜像）
表明这不是孤立事件，而是建立在内容盗窃基础上的商业模式。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

声明

本人善意相信上述对我的版权材料的使用未经本人、本人代理人或法律
授权。本通知中的信息准确无误，本人在伪证罪处罚下声明，本人经
授权代表涉嫌被侵权的专有权的所有者行事。

/s/ [你的全名]
日期：[日期]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

附件清单（共[X]个文件）：
□ 内容对比并排截图（3篇文章）
□ 钓鱼页面同步时间戳及服务器日志
□ 显示自动抓取的服务器日志（IP [203.0.113.45]）
□ 含可见广告单元ID的广告展示截图
□ 域名所有权验证的WHOIS查询结果
□ 显示主机基础设施的Traceroute结果

Subject: Abuse Report - Copyright Infringement via Cloudflare Proxy

To: Cloudflare Trust & Safety
Via: https://www.cloudflare.com/abuse/
Form Selection: "Copyright infringement & DMCA violations"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. REPORTER INFORMATION

   Name: [Your Full Name]
   Email: [Your Email Address]
   Phone: [Your Phone Number]
   Address: [Your Address]
   
   I am the: ☒ Copyright owner
             ☐ Authorized representative

2. CLOUDFLARE-SERVED DOMAIN

   Domain: [mirror-domain.com]
   Specific URLs (if not entire domain):
   • https://[mirror-domain]/article/[slug-1]
   • https://[mirror-domain]/article/[slug-2]
   • https://[mirror-domain]/article/[slug-3]

3. ORIGINAL WORK INFORMATION

   Original website: wuqishi.com
   
   Sample original URLs:
   • https://wuqishi.com/article/[slug-1] (Published: [Date])
   • https://wuqishi.com/article/[slug-2] (Published: [Date])
   
   Description: Personal blog with original technical articles, 
   photography, and creative content. All content is original 
   creation by me, with publication records dating back to [Year].

4. INFRINGEMENT DESCRIPTION

   The domain [mirror-domain.com] is using Cloudflare services to 
   proxy a real-time mirror of my entire website wuqishi.com. This 
   is not legitimate caching; it is active, automated replication 
   designed to steal content and monetize it through advertising.

   Technical evidence of real-time mirroring:
   
   • Honeypot test: 
     - Created: wuqishi.com/secret-test-20260401 at [Date/Time UTC]
     - Detected: [mirror-domain]/secret-test-20260401 at [Date/Time UTC]
     - Time elapsed: 3 minutes 47 seconds
   
   • Content fingerprint verification:
     - Unique string: "wuqishi-verification-XJ9K2M-20260401"
     - MD5 hash of article content: [hash]
     - Identical on both sites (see screenshot)
   
   • Server log analysis:
     - Requests from IP ranges matching Cloudflare's proxy network
     - X-Forwarded-For headers showing true origin: [IP]
     - Request pattern: Automated, not human browsing
   
   • Monetization evidence:
     - AdSense units displayed on mirrored content
     - Affiliate links replaced with attacker's codes
     - Cryptocurrency donation addresses injected

5. GOOD FAITH STATEMENT

   I have a good faith belief that the use of the described material 
   in the manner complained of is not authorized by the copyright 
   owner, its agent, or the law.

6. ACCURACY STATEMENT

   I swear, under penalty of perjury, that the information in this 
   notification is accurate, and that I am the copyright owner or 
   am authorized to act on behalf of the owner of an exclusive right 
   that is allegedly infringed.

7. SIGNATURE

   /s/ [Your Full Name]
   Date: [Date]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ATTACHMENTS:
□ Honeypot page synchronization evidence (timestamps + screenshots)
□ Server logs with Cloudflare proxy headers (X-Forwarded-For, CF-Connecting-IP)
□ Content comparison screenshots (hash verification)
□ Original content publication timestamps
□ Advertising/affiliate code injection evidence on mirror site
□ WHOIS showing Cloudflare as current name server

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ADDITIONAL NOTES:

I understand that Cloudflare cannot remove content from the origin 
server. However, this domain is using Cloudflare's infrastructure to:

1. Obscure the true origin IP of the infringing server (currently 
   hidden behind Cloudflare proxy [IP])
2. Distribute cached copies of my content globally via Cloudflare CDN
3. Provide DDoS protection that shields the infringing operation 
   from countermeasures
4. Potentially manipulate SSL/TLS certificates to appear legitimate

I respectfully request that Cloudflare:

- Terminate service to this domain for Terms of Service violations 
  (Section 4: "Prohibited Activities" - infringement of intellectual 
  property rights)
- Provide the true origin IP to assist with direct DMCA filing 
  (if legally permissible under your transparency policy)
- Flag this domain and associated accounts for monitoring of 
  future abuse
- Consider implementing fingerprinting to detect real-time mirroring 
  at the edge

I have also filed DMCA notices with:
- Hosting provider (identified via [method]): [Provider Name], [Date]
- Domain registrar: [Registrar Name], [Date]
- Google AdSense (for monetization): [Date]

I am prepared to provide additional technical evidence, including 
full packet captures and forensic analysis, upon request.

Thank you for your assistance in protecting content creators' rights.

Sincerely,
[Your Full Name]
[Your Title/Position]
wuqishi.com

主题：滥用投诉 - 通过Cloudflare代理的版权侵权

致：Cloudflare信任与安全团队
通过：https://www.cloudflare.com/abuse/
表单选择："Copyright infringement & DMCA violations"

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 举报人信息

   姓名：[你的全名]
   邮箱：[你的邮箱地址]
   电话：[你的电话号码]
   地址：[你的地址]
   
   本人身份：☒ 版权所有者
             ☐ 授权代表

2. 使用Cloudflare服务的域名

   域名：[镜像域名]
   具体URL（如非整个域名）：
   • https://[镜像域名]/article/[文章别名-1]
   • https://[镜像域名]/article/[文章别名-2]
   • https://[镜像域名]/article/[文章别名-3]

3. 原创作品信息

   原网站：wuqishi.com
   
   原创链接样本：
   • https://wuqishi.com/article/[文章别名-1]（发布于：[日期]）
   • https://wuqishi.com/article/[文章别名-2]（发布于：[日期]）
   
   作品描述：个人技术博客，包含原创文章、摄影作品和创意内容。
   所有内容均为本人原创，发布记录可追溯至[年份]年。

4. 侵权描述

   域名 [镜像域名] 正在使用Cloudflare服务代理我整个网站 
   wuqishi.com 的实时镜像。这不是合法的缓存行为，而是主动的、
   自动化的复制，旨在窃取内容并通过广告获利。

   实时镜像的技术证据：
   
   • 钓鱼测试：
     - 创建：wuqishi.com/secret-test-20260401 于 [UTC日期/时间]
     - 检测：[镜像域名]/secret-test-20260401 于 [UTC日期/时间]
     - 经过时间：3分47秒
   
   • 内容指纹验证：
     - 唯一字符串："wuqishi-verification-XJ9K2M-20260401"
     - 文章内容MD5哈希：[哈希值]
     - 在两站完全一致（见截图）
   
   • 服务器日志分析：
     - 来自与Cloudflare代理网络匹配的IP段的请求
     - X-Forwarded-For头显示真实来源：[IP]
     - 请求模式：自动化，非人类浏览
   
   • 获利证据：
     - 在镜像内容上展示AdSense广告单元
     - 联盟链接被替换为攻击者的代码
     - 被注入加密货币捐赠地址

5. 善意声明

   本人善意相信，以投诉方式描述的材料使用未经版权所有者、
   其代理人或法律授权。

6. 准确性声明

   本人在伪证罪处罚下声明，本通知中的信息准确无误，本人是
   版权所有者或经授权代表涉嫌被侵权的专有权的所有者行事。

7. 签名

   /s/ [你的全名]
   日期：[日期]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

附件清单：
□ 钓鱼页面同步证据（时间戳+截图）
□ 含Cloudflare代理头的服务器日志（X-Forwarded-For, CF-Connecting-IP）
□ 内容对比截图（哈希验证）
□ 原创内容发布时间戳
□ 镜像站广告/联盟代码注入证据
□ 显示Cloudflare为当前DNS的WHOIS查询

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

补充说明：

本人理解Cloudflare无法从源服务器删除内容。然而，该域名正在
使用Cloudflare的基础设施来：

1. 隐藏侵权服务器的真实源IP（当前隐藏在Cloudflare代理 [IP] 后）
2. 通过Cloudflare CDN在全球分发我的内容的缓存副本
3. 提供DDoS保护，为侵权操作屏蔽反制措施
4. 可能操纵SSL/TLS证书以显得合法

本人恳请Cloudflare：

- 因违反服务条款（第4条"禁止活动" - 侵犯知识产权）而
  终止对该域名的服务
- 如法律允许，提供真实源IP以协助直接提交DMCA
  （根据贵司透明度政策）
- 将该域名及相关账户标记以监控未来滥用行为
- 考虑在边缘层实施指纹检测以识别实时镜像

本人也已向以下方提交DMCA通知：
- 主机商（通过[方法]识别）：[主机商名称]，[日期]
- 域名注册商：[注册商名称]，[日期]
- Google AdSense（针对获利行为）：[日期]

本人随时可根据要求提供额外技术证据，包括完整数据包捕获和
取证分析。

感谢协助保护内容创作者的权利。

此致
[你的全名]
[你的职位/头衔]
wuqishi.com

使用建议

💡 关键提示：

1. 所有邮件务必抄送自己邮箱作为备份
2. 使用已读回执（如支持）确认对方查看
3. 建立跟踪表格：投诉对象 | 发送时间 | 自动回复 | 人工回复 | 处理结果
4. 48小时无回复则二次跟进，语气坚定但礼貌
5. 保留所有截图、日志、邮件作为后续法律行动证据

更新记录

• 2026-04-01：更新一些错误链接

• 2026-04-01：首发，整合2025-2026年最新反镜像技术，新增AI爬虫防护、详细测试验证步骤、优化邮件模板证据要求。

• 文章参考链接：

  • 秋风于渭水：https://www.tjsky.net/tutorial/1026
  • 枫林灯语：https://blog.mfwt.top/index.php/archives/1143/

💬 你的镜像站案例：你在处理镜像站时遇到什么奇葩情况？对方用了什么新技术？欢迎在评论区分享，我会更新到文章中帮助更多人。

参考提交格式：镜像域名（可选）+ 发现方式 + 解决方法 + 处理结果

‍

写在前面

最近这几天因为削挂不小心走了代理，导致机场流量告急，实在没法办下只好重启之前的自建节点，所以有了这篇文章，希望可以帮到大家。

在当前的扫描环境下，单纯的加密已不足以自保。本指南通过 3X-UI 搭建目前隐蔽性天花板组合：VLESS 协议、Reality 伪装、Vision 流控，并配合高强度自定义订阅管理，实现真正的“隐身”上网。

一、快速开始：一键安装3X-UI

在你的 VPS（推荐 Ubuntu 20.04+ 或 Debian 11+）中，执行以下官方安装脚本：

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

• 初始设置：安装过程中会提示设置登录 用户名、密码 和 面板端口。

二、 配置参数速查表

三、 核心入站节点：每一项的深度解析

1. 基础信息设置

• 协议 (Protocol)：选择 vless。

  • ​建议：不带冗余加密，是目前 Reality 的最佳搭档。

• 端口 (Port)：建议填写 443。

  • ​说明：443 是标准 HTTPS 端口。如果你在防火墙开启 443 且伪装域名是 Google，流量看起来就是正常的网页访问。

2. 用户与流控 (核心必选)

• ID (UUID)：点击生成。它是你的唯一钥匙。

• 流控 (Flow)：必须填入 xtls-rprx-vision。

  • ​原理：Vision 能够动态填充数据包，消除 TLS 流量的长度特征。如果没有这一项，Reality 的隐蔽性会下降 50% 以上。

3. 传输配置 (Transport)

• 传输协议：选择 tcp。

  • ​说明：Reality 协议目前仅支持 TCP 传输。

• Proxy Protocol：保持 关闭。

  • ​说明：除非你的 VPS 前端挂了 Nginx 转发，否则开启后会导致无法连接。

4. Reality 伪装细节 (证书之魂)

• uTLS：建议选 chrome。

  • ​建议：让你的流量握手指纹看起来像 Chrome 浏览器，最常见也最安全。

• 目标网站 (Dest)：推荐 dl.google.com:443​ 或 www.microsoft.com:443。

  • ​配置建议​：选一个国内能直连、且支持 TLS 1.3 的国外大厂。

• 服务名称 (SNI)：必须与 Dest 域名一致（不带端口），如 dl.google.com。

• Short IDs：点击 [生成] 。

  • ​说明：这是连接时的额外身份 ID。只有带上正确 Short ID 的请求，服务器才会响应，以此防止防火墙主动探测。

• 公私钥 (Public/Private Key)：点击 [Get New Cert] 。

  • ​建议​：自动生成的密钥对极其安全，私钥严禁外泄。

• Vision Seed (随机种子)：点击 [Rand] 。

  • ​说明：增加数据包混淆的随机性，进一步干扰流量分析。

5. 流量嗅探 (Sniffing)

• 开启 (Enabled)：必须开启。

• 协议勾选：勾选 http​, tls​, quic。

• 目标地址覆盖 (Dest Override)：必须开启。

  • ​建议：开启后，如果客户端发出的目标 IP 异常，服务器会根据嗅探到的域名自动修正，确保稳定访问 YouTube 等服务。

四、 订阅服务：深度安全定制

在 「面板设置」 -> 「订阅设置」 区域进行以下配置，锁死面板暴露风险：

1. 订阅服务监听端口 (Subscription Port)

• 设置建议：填入一个未被占用的高位随机端口（如 49152-65535 之间的数字）。
• 细节：严禁与面板登录端口或节点端口共用。

2. 订阅服务 URI 路径 (Subscription URI Path)

• 设置建议：严禁使用默认的 /sub/。
• 格式规范：必须以 / 开头，并以 / 结尾（例如 /my_private_path_99/）。
• 安全逻辑：这相当于订阅链接的“二级密码”。攻击者通过扫描 IP 几乎不可能猜到这个复杂的路径。

五、 部署后的最后检查清单

1. 面板设置：完成订阅设置后，点击 「保存配置」 并点击 「重启面板」 。

2. 防火墙 (安全组)：前往 VPS 控制台，确保 TCP 443 (节点) 和 TCP 2096 (订阅) 均已开放。

3. 时间校准：执行 date​ 命令，确保 VPS 时间与北京时间误差在 90 秒内。

4. 目标网站 (Dest) 的存活检查

   • ​注意点：Reality 借用的“面具”网站如果挂了，你的节点也会跟着挂。
   • ​建议​：定期检查你设置的域名（如 dl.google.com​）是否依然支持 TLS 1.3 且在国内访问顺畅。
   • 避坑：千万不要使用 baidu.com 或已封锁的网站作为 Dest。

5. 流量特征异常警示

   • ​注意点：虽然协议隐蔽，但如果单日流量异常激增（如几百 GB 的持续下载），依然可能引起运营商（ISP）的注意。
   • 建议：尽量模拟正常用户的上网行为，避免 24 小时高频大流量占用。

六、核心客户端适配建议

Shadowrocket (小火箭) —— iOS 首选

小火箭对 Reality 的支持非常成熟，但在手动配置或修改参数时请注意：

• ​类型选择​：协议选 VLESS​，传输方式选 TCP。
• ​安全类型 (Security) ​：务必下拉选择 ​​reality​。
• ​公钥 (PublicKey) ​：填入 3X-UI 面板中生成的 ​Public Key。
• ​流控 (Flow) ​：在 Flow​ 输入框内手动填入 ​​xtls-rprx-vision​。
• ​指纹 (uTLS) ​：在设置最下方的 Fingerprint​ 选为 ​​chrome​。
• ​SNI​：填入与面板一致的伪装域名（如 dl.google.com）。

Loon —— 极致稳定的新秀（推荐）

Loon 的配置文件结构清晰，支持 Reality 的语法如下：

• ​配置关键点​：在节点行中添加 transport=tcp, security=reality, reality-public-key=你的公钥, flow=xtls-rprx-vision。
• ​指纹模拟​：确保 sni​ 字段已填入，并配置 fingerprint=chrome。
• ​优势​：Loon 对 QUIC 嗅探 的处理非常出色，建议在 Loon 内开启“跳过证书验证”以增强稳定性。

Surge —— 强大的网络分析仪

Surge 默认不直接支持 VLESS，通常需要使用插件或配合 External Proxy 逻辑：

• ​适配方案​：建议使用 Sub-Store 进行转换。
• ​配置参数​：在转换后的节点参数中，确保包含 underlying-proxy​ 指向你的 Reality 服务，并手动确认 xtls-rprx-vision 已激活。
• ​注意​：Surge 的 ​MITM​（中间人攻击解密）可能会与 Reality 产生冲突，建议对节点域名执行 skip-proxy 或排除该节点的嗅探。

Quantumult X (圈 X) —— 订阅转换玩家

由于 Quantumult X 核心更新较慢，直接配置 VLESS Reality 较为复杂：

• ​推荐方案​：强烈建议使用 Sub-Store 或后端转换链接，将节点转换为 Trojan 或其他圈 X 原生支持的格式。
• ​手动尝试​：若使用最新测试版，请在配置文件中严格按照 vless=...​ 语法，并确保 reality-public-key 已正确映射。

Windows / Android 通用 (v2rayN / v2rayNG)

• ​内核检查​：确保 Xray-core 版本 ​ ≥ 1.8.0。
• ​一键配置​：直接复制 3X-UI 生成的 vless:// 链接粘贴即可。
• Vision 检查：如果连接后网速极慢或无法打开网页，请检查“流控”一栏是否填错为 xtls-rprx-direct​（应为 vision）。

“虽然 Reality 是目前最隐蔽的方案，但针对部分追求极致分析的高端 iOS 客户端（如 Surge、Quantumult X等），在 3X-UI 中开启一个 Trojan 节点作为备选，是保证全平台 100% 兼容的最优解。”

七、 长期维护与进阶优化

自动更新 Xray 内核

Reality 和 Vision 属于快速迭代的技术。如果内核版本过旧，会导致新版客户端无法连接。

• 操作建议：在系统状态-Xray里，切换更新版本的内核。

定期更换 Reality “面具”（目标网站）

如果你发现原本流畅的节点突然变得断断续续，可能是你借用的伪装网站（Dest）被重点照顾了。

• ​优化方案​：在面板中修改 Dest​ 和 SNI。
• ​冷门推荐​：除了 Google 和 Microsoft，尝试使用一些大型国外高校或技术文档站，例如 www.cisco.com:443​ 或 www.debian.org:443。

解决 Google 搜索频繁跳验证码（开启 Warp）

由于 VPS 的 IP 通常被标记为机房 IP，使用 Google 搜索时常会弹出验证码（Cloudflare 验证）。

• ​解决方案​：在服务器上安装 ​Cloudflare Warp，并在 3X-UI 的「面板设置」中配置“分流路由”，让 Google 流量通过 Warp 节点流出。这能有效“洗白”你的 IP，提升使用体验。

这套配置虽然步骤较多，但只要按部就班，设置妥当，就能在当前的环境下较为安全地使用。有空还可进一步优化内核、系统隐藏等操作，打造“彻底消失”的节点。

初衷

最近一直在鼓捣个人网盘，从Alist换到了OpenList。作为个爱折腾的人，总觉得默认界面差点意思，想找点办法让它更好看。

也不知道从啥时候起，我彻底迷上了液态玻璃效果，尤其是那种全透明、不带模糊的，看着特别通透。干脆自己结合AI整了个OpenList-CSS，把这效果搬到我的网盘界面上。

设计思路

设计思路其实特简单，就想整一个既好看又实用的样式配置。

好看是第一要务

既然要做液态玻璃效果，半透明、毛玻璃这些元素肯定不能少。我用了 backdrop-filter实现模糊效果，搭配半透明背景，层次感一下就出来了。再加上统一的圆角设计，整体看着特别和谐。

实用也不能丢

光好看也不行，还得实用。我在底部加了信息栏，显示版权信息、传统十二时辰、页面加载耗时和网站运行时间，这些小功能都挺实用的。

配置要简单

我知道不是所有人都懂代码，所以把所有可配置的参数都集中到一个区域，用CSS变量管理。就算不懂代码，也能通过修改变量值来定制自己喜欢的效果。

技术实现

CSS部分

• CSS3变量：用 :root定义全局变量，方便统一管理和修改
• backdrop-filter：实现毛玻璃效果，这是液态玻璃效果的核心
• 响应式设计：适配不同屏幕尺寸，手机上也能正常显示
• 统一风格：统一的圆角、间距和颜色方案，整体看着协调

JavaScript部分

• 点击特效：点击页面时会出现随机文字和动画，增加点趣味性
• 时间显示：实时显示当前时辰和页面加载耗时
• 性能优化：用事件委托减少监听器数量，常量定义避免重复创建对象

效果展示

液态玻璃效果

全透明的导航栏和卡片，搭配背景图片，真的就像液态玻璃一样，看着特别有质感。

点击特效

点击页面时会出现随机文字和动画效果，就像在页面上撒了把彩色花瓣，每次点击都有小惊喜。

实用信息

底部信息栏内容虽然简单，但挺实用的，尤其是十二时辰显示，还带着点中国风。

适用范围

虽然我是为OpenList做的，但Alist也能用，操作步骤完全一样。

安装方法

安装超级简单，就几步：

1. 打开OpenList-CSS文件
2. 复制所有代码
3. 登录OpenList或Alist管理后台
4. 找到「全局设置」→「自定义内容」
5. 粘贴代码并保存
6. 刷新前端页面

整个过程不到1分钟，你的网盘界面就能焕然一新。

自定义小技巧

换个背景图片

默认用的是随机图片API，你可以换成自己喜欢的图片：

--bg-image: url("https://example.com/your-image.jpg");

调整透明度

根据背景图片的明暗，调整半透明效果：

--day-bg-opacity: 0.2;          /* 增加背景透明度 */
--day-blur: 5px;               /* 添加模糊效果 */

自定义点击文字

在JavaScript部分找到 VALUES数组，添加你喜欢的文字：

const VALUES = ["💗小乖乖最美💗", "💗小坏蛋最帅💗", "加油！", "你真棒！"];

后续计划

暂时没什么特别的计划，先用着再说。

结语

其实这就是个小项目，主要是满足我自己的审美需求。既然做了，就分享给大家，希望能给用OpenList和Alist的朋友带来点惊喜。

不知道你有没有遇过这种“灵异事件”：

明明屏幕上的小姐姐明艳动人，代码高亮得赏心悦目，结果按下 Win + Shift + S​ 一截图……好家伙！出来的预览图瞬间蒙上了一层厚厚的“白雾”，原本鲜艳的网页像是被丢进漂白水里泡了三天三夜，高光溢出到直接快进到“灵魂升天”。👼

别急着重装系统，这既不是显卡坏了，也不是截图软件抽风。今天我们就来聊聊这个让无数 Windows 用户血压升高的“HDR 截图惨案”，以及如何优雅地干掉它。

1. 为什么会“白茫茫一片真干净”？

这个问题的真凶，其实是色彩管理协议的“代沟” 。

当你开启了 Windows 的 HDR (高动态范围) 模式，屏幕的亮度上限被强行拔高。但目前的浏览器内核（Chromium）和大多数截图工具，默认还是按老掉牙的 sRGB（标准动态范围）来捕捉画面的。

📖 碎碎念：
这好比你试图把一头巨型大象（HDR 信号） 硬塞进一个火柴盒（SDR 图片空间） 里。结果大象没塞进去，盒子先炸了。亮度瞬间挤爆了，高光直接溢出，你得到的截图就像是在正午阳光下强行曝光。

2. 深度根治：三剂良方

为了不让每一张截图都像是在“雪地里求生”，请收下这三招：

剂一：给浏览器下达“色彩戒严令” 😎（最推荐）

如果你发现只有在 Chrome 或 Edge 里截图会发白，那是因为浏览器在 HDR 环境下有点“放飞自我”。我们直接给它下个“死命令”，强制其回归理智。

在地址栏输入并回车：

• Chrome 浏览器：

  chrome://flags/#force-color-profile
  

• Edge 浏览器：

  edge://flags/#force-color-profile
  

操作指南：
找到 ​Force color profile​​ 选项（默认是 Default），将其右侧修改为：sRGB。

📖 碎碎念：
如果你是设计大佬，用的是苹果同款 P3 广色域屏幕，也可以试试设为 Display P3​。这不仅能修复截图发白，色彩看起来还会比 sRGB 更有“果味儿”。改完记得点击右下角的 Relaunch/重启，别白忙活。

剂二：开启 Windows 11 的“后悔药” 🧊

如果你用的是 Win11，官方其实偷偷藏了一个自动校正开关，只是藏得比前女友的照片还深。

1. 搜索并打开系统自带的 “截图工具” App。

2. 点击右上角 ...​ -> 设置。

3. 手动开启以下选项：

   HDR 截图颜色校正: ​On​

剂三：终极暴力美学 🔨

如果你正打着游戏，或者在用一些不听话的第三方截图软件（如 Snipaste 旧版），记住这个系统级全局快捷键：​Win + Alt + B​

• 操作： 截图前按一下（关闭 HDR） -> 截图 -> 截完再按一下（开启 HDR）。
• 黑科技点： 这是 Windows 官方隐藏的 HDR 切换组合键。虽然屏幕会黑屏闪烁 1 秒左右，但它是 100% 解决任何软件截图变色的“物理外挂”。

💡 极客冷知识：为什么苹果没这烦恼？

其实，macOS 在这方面处理得更好，是因为苹果有一套极其严密的色彩管理系统（Color Management） 。无论屏幕多亮，系统底层都会在截图的一瞬间自动进行“色调映射”。

而 Windows 这边，由于显示器质量参差不齐（有几千块的 OLED，也有几百块的“伪 HDR”），系统和软件之间经常各说各的话。支持 HDR 的显示器越来越多，但软件代码可能还是 10 年前写的。

📖 碎碎念：
换个角度想，截图变白其实是一种 “富贵的烦恼” 。这起码说明你的屏幕素质不错，真的能跑 HDR！如果你的屏幕只有 250 尼特亮度，它连变白的机会都没有……💁‍♂️

🎁 写在最后

那么问题来了： 你遇到截图发白的时候，第一反应是觉得显卡要崩了，还是觉得显示器该换了？欢迎在评论区分享你的“翻车”瞬间！👇

写在最前面

因为将我的群晖DSM升级到7.3版本，导致之前用代码安装的rclone直接没了，所以就想着用Docker部署rclone，将遇到的问题到最后完成部署后的结果整理成了这篇文章。

前言：为什么你之前的挂载都失败了？

许多群晖用户在尝试通过 OpenList/Alist 挂载网盘时，往往会遇到三个看似"玄学"的问题：

本文核心解决方案：通过 Docker Rclone 配合 挂载传播（Mount Propagation） 技术，构建一个稳定、高性能的网盘挂载架构。

第一阶段：宿主机底层环境加固（SSH 必做）

这是整个方案的"地基"。地基不稳，后续容器运行再顺畅，Plex 也无法识别文件。

1. 开启 FUSE 内核支持

FUSE（用户态文件系统）是 Rclone 在 Linux 上模拟硬盘的基础依赖：

sudo modprobe fuse

2. 修改存储卷共享属性（核心步骤）

群晖默认禁止容器修改宿主机挂载表，需手动将存储卷改为 shared​ 模式：

# 将 /volume4 替换为你实际的存储卷路径（如 /volume1）
sudo mount --make-shared /volume4

3. 建立标准化目录结构

建议统一存放 Docker 配置文件，便于日后迁移和维护，以下为示例：

# Rclone 配置文件目录
mkdir -p /volume4/docker/rclone/config

# VFS 缓存目录（建议选用 SSD 卷，加速 Plex 元数据扫描）
mkdir -p /volume4/docker/rclone/cache

# Plex 最终扫描的物理挂载点（需保持为空文件夹）
mkdir -p /volume4/OpenList

第二阶段：精细化配置 Rclone 凭据

1. 密码加密（不能填明文哦）

Rclone 配置文件禁止存储明文密码。执行以下命令生成加密字符串：

docker run --rm rclone/rclone obscure [你的OpenList密码]

记录输出结果（如 EY_L_2...​），用于下一步配置。

2. 编写 rclone.conf

编辑 /volume4/docker/rclone/config/rclone.conf​：

[openlist]
type = webdav
url = http://127.0.0.1:5244/dav    	# 必须包含端口和路径
vendor = other						# 没错，就是other
user = admin						# 你的用户名
pass = EY_L_2...                  	# 填入上一步生成的加密字符串

⚠️ 关键细节：

• URL 格式：必须包含端口号 5244​ 和路径 /dav​，端口号请填写你自己的。

• 禁止尾随斜杠：URL 结尾不加 /​，否则可能会触发 405 Method Not Allowed​ 错误。

第三阶段：部署高性能挂载容器

部署前建议清理可能存在的僵尸挂载点：

sudo fusermount -u -z /volume4/OpenList 2>/dev/null || true

执行部署命令：

docker run -d \
  --name rclone-mount \
  --restart always \
  --privileged \
  --network host \
  --device /dev/fuse \
  -e PUID=0 \
  -e PGID=0 \
  -e TZ=Asia/Shanghai \
  -v /etc/localtime:/etc/localtime:ro \
  -v /volume4/docker/rclone/config:/config/rclone \
  -v /volume4/docker/rclone/cache:/cache \
  -v /volume4/OpenList:/data:shared \
  rclone/rclone \
  mount openlist:/ /data \
  --config /config/rclone/rclone.conf \
  --allow-other \
  --allow-non-empty \
  --vfs-cache-mode full \
  --vfs-cache-max-size 20G \
  --vfs-cache-max-age 24h \
  --cache-dir /cache \
  --buffer-size 64M \
  --vfs-read-chunk-size 32M \
  --vfs-read-chunk-size-limit 1G \
  --attr-timeout 10s \
  --dir-cache-time 24h \
  --umask 000

核心参数解析

第四阶段：Docker 版 Plex 的特别配置

若使用 Docker 部署 Plex，需进行路径二次穿透：

1. 添加卷映射

在 Plex 容器配置中增加：

• 宿主机路径：/volume4/OpenList​

• 容器路径：/video​（可自定义）

2. 必须添加 :shared​ 后缀

-v /volume4/OpenList:/video:shared

原理说明：不加 :shared​ 时，宿主机挂载点更新后，Plex 容器因命名空间隔离无法感知变化。

第五阶段：自动化运维与故障排查

1. 开机自动配置（群晖任务计划）

群晖重启后内核设置会重置。进入 控制面板 > 任务计划 > 新增 > 触发的任务：

• 事件：开机

• 用户：root

• 脚本内容：

#!/bin/bash
modprobe fuse
mount --make-shared /volume4

2. 常见故障速查表

结语

完成上述配置后，你的网盘已通过 Rclone 无缝"寄生"在群晖本地。Plex 扫描 /volume4/OpenList​ 时，体验将与本地硬盘无异。

🎬 享受你的高清私人影院吧！

💡 进阶建议：Plex 资料库优化

进入 Plex 设置 > 资料库，建议调整以下选项以降低网盘 API 调用频率：

• ✅ 禁用 "定期扫描"

• ✅ 禁用 "检测到更改时扫描"

• ✅ 改为 手动扫描 或设置 凌晨低峰期定时扫描

此举可显著降低网盘服务商的流量风控风险，提升长期稳定性。

引言

因为在使用SVG图标的是否发现Base64代码真的很不直观，想预览一个打开一个浏览器标签，于是就想着将这些都在一个页面预览不就好了？所以，通过Trae的助力，开发了这个SVG图标库。

预览地址：

让图标管理变得简单

有以下特点😂：

• ✅ 显示SVG图标并支持点击复制base64编码
• ✅ 支持提交新的SVG图标
• ✅ 响应式设计，适配不同设备
• ✅ 现代化的液态玻璃UI效果
• ✅ 支持批量上传SVG图标
• ✅ 自动检测重复图标
• ✅ 支持多种输入格式（SVG代码、纯Base64编码、带data URL前缀的Base64编码）
• ✅ 完善的表单验证和错误处理
• ✅ CSRF防护确保安全

1. 直观的图标展示

SVG图标库采用网格布局展示所有图标，每个图标都以卡片形式呈现，悬停时会有微妙的动画效果。用户可以一目了然地看到所有可用的图标，无需在无数个文件夹中翻找。

界面展示：

2. 便捷的复制功能

用户只需点击图标，在弹出的模态框中点击相应按钮，就能：

• 一键复制SVG代码，直接用于HTML
• 一键复制Base64编码，带data URL前缀，可直接粘贴到CSS中
• 复制成功后会显示通知提示，确保操作成功

界面展示：

3. 图标添加功能

支持多种格式的输入：

• 直接上传SVG代码
• 上传Base64编码（带或不带data URL前缀）
• 批量上传多个Base64编码（一次粘贴多个，系统自动处理）
• 智能验证，确保SVG内容有效
• 自动去重，防止重复图标

界面展示：

4. 现代美观的界面

采用流行的液态玻璃UI设计风格，使用backdrop-filter和box-shadow实现现代化的模糊效果。界面简洁大方，动画流畅自然，响应式设计确保在手机、平板和桌面设备上都能完美展示。

界面展示：

技术实现

前端技术

• HTML5：语义化标签，良好的结构
• CSS3：现代CSS特性，包括变量、动画、响应式设计
• JavaScript (ES6+) ：模块化代码组织，事件处理
• 液态玻璃UI：使用backdrop-filter和box-shadow实现

后端技术

• PHP 8.0+ ：服务器端逻辑处理
• 文件系统：存储SVG图标数据
• 会话管理：实现PRG模式，防止表单重复提交

代码结构

svg/
├── index.php          # 主入口文件
├── icons.txt          # 存储SVG图标数据
├── includes/
│   ├── config.php     # 配置文件
│   ├── security.php   # 安全相关功能
│   └── svg_manager.php # SVG图标管理功能
└── assets/
    ├── css/
    │   └── style.css  # 样式文件
    └── js/
        └── script.js  # JavaScript文件

问题与解决方案

1. Cloudflare兼容性问题

问题表现：部署到使用Cloudflare加速的服务器后，点击图标或按钮没有反应，浏览器控制台显示JavaScript错误。

具体影响： 核心功能完全无法使用，用户无法预览或复制图标，也无法添加新图标等问题

技术原因：Cloudflare的Rocket Loader功能会异步加载和执行JavaScript代码，干扰了事件监听器的绑定，导致事件处理函数无法正常触发。

// 使用捕获阶段的事件监听器
this.DOM.iconGrid.addEventListener('click', (event) => {
    const card = event.target.closest('.icon-card');
    if (card) {
        event.stopPropagation();
        this.openPreviewModal(card);
    }
}, true); // 使用捕获阶段

// 初始化 - 使用更可靠的方式，避免Cloudflare干扰
(function() {
    // 等待DOM加载完成
    function initWhenReady() {
        if (document.readyState === 'loading') {
            document.addEventListener('DOMContentLoaded', function() {
                SvgIconLibrary.init();
            });
        } else {
            SvgIconLibrary.init();
        }
    }    // 立即执行初始化
    initWhenReady();    // 额外的保险措施：延迟初始化，确保所有资源都已加载
    setTimeout(function() {
        if (!window.SvgIconLibrary || !window.SvgIconLibrary.DOM || Object.keys(window.SvgIconLibrary.DOM).length === 0) {
            console.log('Secondary initialization attempt');
            SvgIconLibrary.init();
        }
    }, 1000);
})();

2. ARIA可访问性问题

问题表现：浏览器控制台报ARIA可访问性错误，提示"Blocked aria-hidden on an element because its descendant retained focus"，影响网站的可访问性评分。

技术原因：当关闭模态框时，模态框中的按钮仍然保持焦点，而模态框被设置为aria-hidden="true"，违反了WAI-ARIA规范，因为辅助技术不应该将焦点隐藏在用户看不到的元素上。

closePreviewModal: function() {
    // 确保焦点不留在隐藏的元素中
    const focusedElement = document.activeElement;
    if (this.DOM.previewModal.contains(focusedElement)) {
        // 将焦点移到页面主体
        document.body.focus();
    }
  
    this.DOM.previewModal.classList.remove('show');
    this.DOM.previewModal.setAttribute('aria-hidden', 'true');
    // 等待动画完成后隐藏
    setTimeout(() => {
        this.DOM.previewModal.style.display = 'none';
        // 清除当前图标数据
        this.currentIconData = null;
    }, 300);
},

3. 字体加载问题

问题表现：网站加载时，浏览器控制台显示字体加载失败的错误，提示"Failed to load resource: net::ERR_CONNECTION_CLOSED"。

技术原因：使用的国内一些字体库连接不稳定，导致字体无法正常加载，影响网站的视觉效果。

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700&family=Poppins:wght@400;500;600;700&display=swap">

4. 表单重复提交问题

问题表现：用户提交表单后刷新页面，会导致表单重复提交，可能造成重复数据或其他意外行为。

技术原因：传统的表单提交方式会在页面刷新时重新发送请求，导致重复提交。

if ($successCount > 0) {
    $_SESSION['message'] = '成功添加 ' . $successCount . ' 个SVG图标！';
    // 重定向到同一个页面，防止重复提交
    header('Location: ' . $_SERVER['PHP_SELF']);
    exit;
}

结语

SVG图标库是一个简洁、高效的工具，解决了前端开发中图标管理的实际问题。通过模块化的代码结构、现代化的UI设计、完善的功能实现以及与Cloudflare的兼容性优化，它为用户提供了一个高效、可靠的SVG图标管理解决方案。

每次在博客留言时都要反复输入昵称、邮箱和网址，是不是觉得很麻烦？今天分享一个我一直在用的「偷懒」神器 —— 一个能自动填写评论信息的浏览器书签脚本。

一、什么是书签脚本？

浏览器书签不仅能保存网址，还可以保存一段 JavaScript 代码。当你点击这个特殊的书签时，代码就会在当前页面执行。利用这个特性，我们可以创建一键操作的便捷工具。

二、快速创建你的自动填充书签

1. 在浏览器书签栏右键 → 选择「添加网页」
2. 名称填写：一键评论填充
3. 网址栏粘贴以下代码（​请先阅读下方的配置说明）：

javascript:(function(){var d={n:'蛋蛋之家',e:'me@wuqishi.com',w:'https://wuqishi.com'},s={n:['#author','input[name="comname"]','#inpName','input[name="author"]','#ds-dialog-name','#name','input[name="nick"]','#comment_author'],e:['#mail','#email','input[name="commail"]','#inpEmail','input[name="email"]','#ds-dialog-email','input[name="mail"]','#comment_email'],w:['#url','input[name="comurl"]','#inpHomePage','#ds-dialog-url','input[name="url"]','input[name="website"]','#website','input[name="link"]','#comment_url']},f=0;for(var t in s)for(var i=0;i<s[t].length;i++)try{var e=document.querySelector(s[t][i]);if(e&&e.tagName==='INPUT'){e.value=d[t];e.dispatchEvent(new Event('input',{bubbles:!0}));e.dispatchEvent(new Event('change',{bubbles:!0}));f++;break}}catch(r){}if(f>0){var m=document.createElement('div');m.textContent='✅ 已填充 '+f+' 项';m.style.cssText='position:fixed;top:20px;right:20px;background:#4CAF50;color:white;padding:12px 24px;border-radius:4px;z-index:999999;font-family:sans-serif;box-shadow:0 2px 10px rgba(0,0,0,0.2);animation:g 3s ease';document.body.appendChild(m);setTimeout(function(){m.remove()},3000);if(!document.querySelector('#x')){var a=document.createElement('style');a.id='x';a.textContent='@keyframes g{0%{opacity:0;transform:translateY(-10px);}15%{opacity:1;transform:translateY(0);}85%{opacity:1;transform:translateY(0);}100%{opacity:0;transform:translateY(-10px);}}';document.head.appendChild(a)}}})()

三、配置说明（重要！）

在使用前，你需要修改代码开头的个人信息：

var d={
    n:'蛋蛋之家',              // 改成你的昵称
    e:'me@wuqishi.com',       // 改成你的邮箱
    w:'https://wuqishi.com'    // 改成你的网站
}

将 蛋蛋之家​、me@wuqishi.com​、https://wuqishi.com分别替换为你自己的昵称、邮箱和网址。

四、这个脚本有什么特点？

1. 智能匹配多种博客系统

脚本内置了多种常见博客评论框的选择器，包括：

• WordPress 默认评论框
• Typecho 评论系统
• Hexo 常见主题
• Disqus 评论插件
• 以及各种自定义的评论表单

2. 友好的视觉反馈

成功填充后，页面右上角会显示绿色提示框，显示已填充的项数，3秒后自动消失。

3. 触发表单事件

不仅填充值，还会触发 input​和 change事件，确保一些依赖这些事件的表单验证能够正常工作。

4. 安全可靠

• 只在前端操作，不会上传你的信息
• 有错误处理机制，避免脚本崩溃
• 只操作 INPUT 元素，不会误改其他内容

五、工作原理简析

脚本的核心逻辑很巧妙：

1. ​数据准备：定义个人信息和常见选择器
2. ​智能查找：按顺序尝试各种可能的选择器
3. ​安全填充：找到匹配的输入框后填充并触发事件
4. ​结果反馈：统计成功数并显示提示

六、使用场景与技巧

适用场景：

• 经常在多个博客留言的创作者
• 需要测试评论功能的前端开发者
• 喜欢在不同平台交流的技术爱好者

实用技巧：

1. ​创建多个版本：可以创建不同身份的书签，用于不同场景
2. ​定期更新选择器：遇到无法填充的博客，可以查看其表单元素并添加对应选择器
3. ​配合其他脚本：可以与自动填充评论内容的脚本结合使用

七、进阶思考

这个脚本虽然简单，但体现了「自动化」的核心思想 —— 将重复的操作交给代码。其实很多日常工作都可以通过类似的小工具来提升效率：

• 表单自动填充
• 页面信息提取
• 批量操作自动化

技术应该服务于人，让人从重复劳动中解放出来，专注于更有价值的事情。

八、注意事项

1. ​仅在信任的网站使用，避免在不安全的网站执行任何脚本
2. ​及时更新选择器，新的博客系统可能需要添加新的选择器
3. ​做好备份，浏览器书签同步是个好习惯

结语

在马年的新春里，愿这个小工具能像一匹快马，助你在博客的世界里畅行无阻。技术存在的意义就是让生活更简单，让交流更顺畅。

现在就去创建属于你自己的「一键填充」书签吧！如果在使用中遇到问题，或者有更好的选择器建议，欢迎在评论区交流分享。

让代码代替重复，让思考创造价值。

本文基于 siyuan-patch项目，旨在探讨如何通过补丁技术解锁思源笔记的更多可能性。请注意，本文仅作技术探讨，请遵守相关法律法规。

引言：当开源遇上“本地VIP”

思源笔记（SiYuan）作为一款优秀的开源知识管理工具，以其强大的块级编辑和双向链接功能深受用户喜爱。然而，官方版本中部分高级功能（如第三方云同步、PDF导出水印等）通常需要订阅会员才能使用。对于追求极致本地化或希望自定义同步方案的用户来说，这无疑是一道门槛。

siyuan-patch 项目正是为了解决这一痛点而生。它通过技术手段，在不破坏软件核心功能的前提下，解锁了部分原本需要付费才能使用的特性，让用户能够更自由地掌控自己的数据。

核心功能：解锁了什么？

根据项目文档，该补丁主要实现了以下关键功能的解锁：

1. ​本地VIP权限：解锁了官方原本限制的VIP功能，如高级导出、搜索资源文件内容等。

2. ​第三方同步支持：支持使用第三方 S3 或 WebDAV 服务进行数据同步和备份（注意：不支持坚果云）。

3. ​隐私与体验优化：

   • 默认关闭了 Google Analytics 和自动上传报错信息，保护用户隐私。
   • 默认关闭自动下载更新安装包，避免意外更新导致补丁失效。
   • 支持点击关闭按钮后缩小到托盘，提升操作体验。

技术实现：补丁的艺术

该项目并非简单的破解，而是基于对思源笔记客户端（Electron应用）的深度分析。通过修改渲染进程（Renderer）中的特定逻辑，绕过了官方的权限校验机制。这种“打补丁”的方式，相比直接修改源码，具有更高的灵活性和兼容性。

技术实现原理

1. ​目标定位：思源笔记是基于 Electron 开发的桌面应用。该补丁主要针对渲染进程（负责界面显示和交互）中的 JavaScript 代码进行拦截和修改。
2. ​Hook 机制​：通过修改 Electron 的启动参数或注入脚本，在应用启动时加载自定义的补丁代码。这些代码会重写（Override）原有的函数，例如将 isPro​或 isPaid​等权限校验函数的返回值强制改为 true。
3. ​文件替换​：对于某些版本，补丁可能直接替换了应用目录下的 app.asar​文件（Electron 应用的打包文件）中的特定模块，或者修改了 package.json中的启动脚本。

使用指南：如何安全部署

前提条件

• 已安装官方版本的思源笔记（建议关闭自动更新）。
• 下载 siyuan-patch 项目中的对应版本补丁文件（通常为 .asar 文件或脚本文件）。

详细安装步骤

步骤 1：备份原始文件

在操作前，务必备份思源笔记的安装目录。对于 Windows 用户，路径通常为 C:\Users\[用户名]\AppData\Local\Programs\SiYuan​；对于 macOS 用户，路径通常为 /Applications/SiYuan.app/Contents/Resources​。备份 app.asar文件，这是核心资源文件。

步骤 2：应用补丁

根据补丁类型，操作分为两种模式：

• 模式 A：替换 .asar 文件（常见）

  1. 关闭思源笔记进程。
  2. 将下载的补丁文件（如 app.asar​）复制到思源笔记的安装目录下的 resources​文件夹中，覆盖原有的 app.asar文件。
  3. 重新启动思源笔记。

• 模式 B：使用脚本或命令行参数（高级）

  1. 如果补丁提供的是脚本（如 .bat 或 .sh），右键以管理员权限运行该脚本。
  2. 如果补丁要求修改启动参数，需要在思源笔记的快捷方式属性中，在“目标”字段末尾添加补丁指定的参数（如 --disable-gpu-sandbox等，具体视补丁说明而定）。

步骤 3：验证安装

启动思源笔记后，检查以下功能是否已解锁：

• 点击菜单栏的“关于”，查看是否显示“已激活”或“Pro”状态。
• 尝试导出 PDF，检查是否不再有水印。
• 尝试使用第三方同步（如 WebDAV），检查是否不再提示需要会员。

当然你也可以直接下载项目里构建好的软件直接使用。

可能遇到的问题及解决方案

1. 问题：应用闪退或无法启动

   • ​原因：补丁版本与思源笔记版本不匹配，或者补丁文件损坏。

   • ​解决方案：

     • 恢复备份的原始 app.asar文件，确保应用能正常启动。
     • 检查你下载的思源笔记版本号（如 v3.0.10），下载对应版本的补丁文件。不要跨大版本使用补丁。
     • 重新下载补丁文件，确保下载完整。

2. 问题：补丁应用后功能未生效（仍提示需要会员）

   • ​原因：补丁未成功加载，或者应用缓存未清除。

   • ​解决方案：

     • 清除缓存：关闭思源笔记，删除用户数据目录下的 temp​和 cache​文件夹（路径通常在 用户目录/.siyuan/下），然后重启。
     • 检查权限：在 Windows 系统下，如果直接覆盖文件失败，可能是权限不足。请关闭思源笔记后，右键点击补丁文件或脚本，选择“以管理员身份运行”。
     • 杀毒软件拦截：部分杀毒软件（如 Windows Defender、360 等）可能会将补丁文件误报为病毒并隔离。需要在杀毒软件中恢复文件或添加信任。

3. 问题：同步功能异常或数据丢失

   • ​原因：补丁修改了同步逻辑，或者与官方服务器通信时出现校验错误。

   • ​解决方案：

     • 数据安全第一：在使用补丁进行第三方同步（如自建 S3）前，务必在官方版本中先进行完整的数据备份（导出 .sy.zip 文件）。
     • 配置检查：如果使用 WebDAV 同步，请确保服务器地址、用户名和密码填写正确，且服务器支持 WebDAV 协议。

4. 问题：系统提示“文件正在被使用”无法覆盖

   • ​原因：思源笔记进程未完全退出。

   • ​解决方案：

     • 打开任务管理器（Ctrl+Shift+Esc），结束所有名为 SiYuan 或 electron 的进程。
     • 或者重启电脑后再进行操作。

风险与思考

• ​稳定性风险：非官方补丁可能无法保证与官方最新版本的完全兼容，建议在稳定版本上使用。非官方补丁可能导致应用崩溃、数据损坏或功能异常。建议仅在测试环境或非重要数据上使用。
• ​安全风险：使用第三方修改的软件存在潜在的安全隐患，请从可信渠道下载。从第三方渠道下载的补丁文件可能包含恶意代码。请务必从可信来源（如项目的 GitHub Releases）下载，并在安装前使用杀毒软件扫描。
• ​法律与道德：虽然思源笔记是开源软件，但解锁付费功能可能涉及版权问题。建议用户根据自身需求权衡利弊，支持正版软件的发展。解锁付费功能可能违反软件的使用协议。请尊重开发者的劳动成果，在条件允许时支持正版。

结语

siyuan-patch 项目展示了开源社区对软件自由度的追求。它让用户能够根据自己的需求定制软件行为，而不是被动接受软件的限制。对于技术爱好者或对数据隐私有极高要求的用户来说，这无疑是一个值得尝试的解决方案。

​最后提醒：技术是一把双刃剑，请合理使用，并尊重开发者的劳动成果。

引言：当“安全”变成“枷锁”

在数字化时代，多因素身份验证（MFA）是保护账户安全的重要屏障。然而，当你的旧手机意外丢失、损坏，或者更换新设备时忘记迁移 Oracle Authenticator 应用，这道屏障就会瞬间变成一堵无法逾越的高墙。

如果你正因无法登录 Oracle Cloud 而焦头烂额，别担心，这篇文章将为你提供一个无需联系客服、无需漫长等待的“自救”方案。

核心原理：利用 IDCS 管理控制台

Oracle Cloud 的身份验证通常由 Oracle Identity Cloud Service (IDCS) 管理。当你无法通过 MFA 验证时，可以通过直接访问 IDCS 的管理控制台来临时禁用 MFA 或生成绕过代码。

详细操作步骤

第一步：获取你的 IDCS 实例 URL

1. 打开 Oracle Cloud 登录页面（通常是 https://cloud.oracle.com）。

2. 在输入邮箱和密码的界面，不要点击登录。

3. 查看浏览器地址栏，找到以 https://idcs-********.identity.oraclecloud.com/开头的网址，并完整记录下来。

第二步：构造管理页面 URL

将第一步记录的 URL 进行修改，构造出可以直接访问 MFA 管理页面的地址。

原始 URL 示例：

https://idcs-xxxxx.identity.oraclecloud.com/

修改后的 URL 示例：

https://idcs-xxxxx.identity.oraclecloud.com/ui/v1/myconsole?root=my-info&my-info=my_profile_security

注意：请将 *xxxxx*替换为你实际记录的数字或字符。

第三步：管理 MFA 设置

1. 在浏览器中打开修改后的新 URL。

2. 页面加载后，你应该能看到 “Multi-Factor Authentication” 或 “Security” 相关的管理选项。

3. 根据你的需求选择以下操作之一：

   • 临时禁用 MFA：找到开关选项，暂时关闭 MFA 验证。 （强烈建议登录后立即重新开启）

   • 生成绕过代码：如果系统支持，生成一次性使用的绕过代码，用于本次登录。

   • 重新配置验证器：删除旧的验证器绑定，并重新扫描二维码绑定新设备。

第四步：重新登录并加固安全

成功进入控制台后，请务必执行以下操作，以防未来再次陷入困境：

1. 重新启用 MFA：如果你选择了临时禁用，请立即重新启用。

2. 生成备用代码：在 MFA 设置中，找到“生成备用代码”或“Bypass Codes”选项，生成一组代码并安全保存（建议打印或存储在密码管理器中）。

3. 绑定备用设备：如果条件允许，将 Oracle Authenticator 绑定到两台设备上（如手机和平板）。

风险提示与最佳实践

• 安全风险：绕过 MFA 会暂时降低账户的安全性。请确保在操作过程中没有可疑的网络环境，操作完成后立即恢复安全设置。

• 数据备份：定期导出 Oracle Authenticator 的密钥或使用支持云同步的验证器应用（如 Microsoft Authenticator、Authy），避免单点故障。

• 官方支持：如果上述方法因权限或配置问题无法生效，最后的途径是联系 Oracle 官方支持，通过验证身份信息来重置 MFA。

总结

技术故障并不可怕，可怕的是失去对系统的控制权。通过上述 URL 构造技巧，你可以快速夺回 Oracle Cloud 的访问权限。记住，安全工具是为你服务的，而不是束缚你的。希望这篇指南能帮你顺利“回家”。

本文基于 Oracle Cloud Infrastructure 官方文档及社区实践经验整理，具体界面可能因版本更新略有差异。

2026年4月13日更新

根据评论反馈，我又去查了一下Oracle的官方政策。

两步验证信息官方地址：

https://docs.oracle.com/en-us/iaas/Content/GSG/Tasks/signinginIdentityDomain.htm#faq_identity_2_step_verification_and_alternate_login

其中有：

Resetting MFA Factors for Your Account
重置您帐户的多因素身份验证 (MFA) 因素

答复是：

If you need the MFA factors reset for your account, for example if you lost your device or deleted the app from your phone, you must contact an administrator to reset them for you. 
如果您需要重置帐户的多因素身份验证 (MFA) 因素，例如您的设备丢失或从手机中删除了应用程序，则必须联系管理员为您重置。

我在其中找到：

Contacting Support When Not Signed In to the Oracle Cloud Console
未登录 Oracle 云控制台时如何联系支持人员

步骤如下：

1. Go to the Contact us page.
   请前往 “联系我们” 页面。

2. Select Open a live chat link located under Chat with Oracle Sales.
   选择“打开与 Oracle 销售人员聊天” 下方的在线聊天链接。

3. In the Oracle Chatbot, select Get Support.
   在 Oracle 聊天机器人中，选择 “获取支持” 。

4. Select the type of support you need, for example, Cloud Infrastructure (OCI) including Free Trial.
   选择您需要的支持类型，例如云基础设施 (OCI)，包括免费试用 。

5. From the chat response select Cloud Support Chat.
   从聊天回复中选择云支持聊天 。

6. Select a Country/Region, enter your Email Address, and then start the chat.
   选择国家/地区 ，输入您的电子邮件地址 ，然后开始聊天。

具体地址是：

以上，诸君共勉~

什么是“萌国ICP备案”？

“萌国ICP备案”（简称“萌备”）并非中国工信部官方认可的备案，而是一个​非官方的、基于兴趣爱好的虚拟备案系统。它主要流行于个人站长、二次元文化爱好者或使用海外服务器（无需国内备案）的网站中，用于在网站页脚添加一个“萌ICP备”的链接，增加趣味性。

​官方口号：我们与世无争，与人无碍，不爱也请别伤害。

为什么要加入“萌备”？

对于使用海外服务器（如GitHub Pages、Vercel等）搭建的个人博客或网站，由于服务器不在中国大陆，无法进行工信部官方备案。为了给网站一个“身份标识”，也为了在页脚增加一点趣味性，许多站长会选择加入“萌国ICP备案”。

它与官方ICP备案的区别

如何申请“萌国ICP备案”？

申请流程非常简单，全程在线操作，无需提交身份证件或等待审核：

1. ​访问官网：打开萌国ICP备案查询系统（https://icp.gov.moe）。
2. 申请备案：点击下方“加入”，选择一个自己喜欢的号码（通常为8-10位数字，如20262574）。
3. ​填写信息：输入你的网站名称、域名、首页地址以及你的邮箱。
4. 获取代码：申请通过后，系统会生成一段HTML代码（如 <a href="https://icp.gov.moe/?keyword=20262574" target="_blank">萌ICP备20262574号</a>）。
5. ​部署网站：将这段代码添加到你的网站页脚（Footer）中，即可显示备案号。

本站的“萌备”信息

本站已成功加入“萌国ICP备案”联萌，备案号如下：

萌ICP备20262574号

点击备案号即可跳转至萌国备案查询系统，查看本站的备案信息。

注意事项

• 适用范围：仅适用于个人博客、兴趣站点或使用海外服务器的网站。
• ​法律效力​：萌国ICP备案​不具备法律效力​，仅供娱乐和同好标识。如果你的网站服务器在中国大陆，必须进行工信部官方备案，否则网站会被屏蔽。
• ​查询真伪：在查询网站备案信息时，请务必以工信部官网（beian.miit.gov.cn）为准，不要将“萌备”误认为是正规备案。

结语

加入“萌国ICP备案”是一种次元文化的展现，也是站长们对网络世界的一种浪漫情怀。希望本站的这个小彩蛋能给你带来一丝乐趣！

每月月底，你是否也曾这样加班：

面对满屏数据，手动将公式里的“六月”逐个改为“七月”，键盘声夹杂着叹息，窗外天色早已暗下。这不是你不努力，而是方法该升级了。

事实上，只需掌握几个核心公式，你就能将那些重复、繁琐的操作交给 Excel 自动完成。本文不涉及复杂概念，只分享即学即用的实战技巧，帮你每月省下几个小时。

🔄 痛点一：每月手动调日期，改到眼花手酸

​过去的做法：每月初打开报表，人工查找并修改所有日期相关的公式，例如把“2024-06-01”更新为“2024-07-01”。

​现在的解法​：用一个公式实现​日期自动识别与更新。

=SUMIFS(销售表!$C:$C, 
        销售表!$A:$A, ">=" & EOMONTH(TODAY(), -1) + 1,
        销售表!$A:$A, "<=" & EOMONTH(TODAY(), 0))

​公式拆解（其实很简单）：

• ​TODAY()：获取今天日期
• ​EOMONTH(TODAY(), -1)：获取上个月的最后一天
• ​EOMONTH(TODAY(), -1) + 1​：上个月最后一天 + 1天 = 本月第一天
• ​EOMONTH(TODAY(), 0)​：获取本月最后一天

✅ ​效果​：无论何时打开工作簿，该公式都会​自动计算当月数据。

✅ ​搭配使用：

=SUMIFS(销售表!$C:$C, 
        销售表!$A:$A, ">=" & EOMONTH(TODAY(), -2) + 1,
        销售表!$A:$A, "<=" & EOMONTH(TODAY(), -1))

此公式用于计算上月同期数据，便于进行环比分析。

📍 ​动手试试：在你现有的月报中，找一个手动输入日期的公式，用上述动态公式替换它。感受一下下个月自动更新的便利。

🔍 痛点二：多条件筛选，反复操作效率低

​典型场景：“请统计华东区产品A在三月份的销售额，并扣除退货部分。”

​传统操作：分别筛选区域、产品、日期和状态，最后查看合计。

​高效做法​：使用 SUMIFS一次性完成多条件汇总。

=SUMIFS(金额列, 
        区域列, "华东",
        产品列, "产品A",
        日期列, ">=2024-03-01",
        日期列, "<=2024-03-31",
        状态列, "<>退货")  /* “<>”表示“不等于” */

📍 ​进阶应用：

若在表格空白区域设置下拉菜单（通过“数据验证”实现），可将公式稍作调整：

=SUMIFS(金额列, 区域列, $G$2, 产品列, $G$3, ...)

（其中 $G$2​、$G$3为下拉菜单所在单元格）

通过点选下拉菜单，结果实时更新——一个专属数据查询面板就此诞生。

💡 ​小挑战​：下次遇到多条件汇总时，先别急于点击筛选按钮，尝试用 SUMIFS一次性得出结果，体验“秒出答案”的效率。

🧹 痛点三：数据混乱不规范，整理费时费力

系统导出的数据常伴有各种“顽疾”：

• 日期格式五花八门
• 文本前后存在空格
• 多项信息挤在同一单元格

​三个公式，精准清理：

1. 清除空格与不可见字符

=TRIM(CLEAN(A2))

​TRIM​去除首尾空格，CLEAN删除非打印字符。

2. 统一日期格式

=IFERROR(DATEVALUE(A2), 
         DATEVALUE(SUBSTITUTE(SUBSTITUTE(A2, "年", "-"), "月", "-")))

先尝试常规转换，若失败则替换“年月”为“-”后再转换。

3. 拆分合并内容

假设 A2 单元格内容为“北京-朝阳区-销售一部”：

城市: =LEFT(A2, FIND("-", A2) - 1)
区域: =MID(A2, FIND("-", A2) + 1, 
           FIND("-", A2, FIND("-", A2) + 1) - FIND("-", A2) - 1)
部门: =RIGHT(A2, LEN(A2) - FIND("-", A2, FIND("-", A2) + 1))

将公式向右填充，即可​快速拆分整列数据。

📍 ​经验分享：你遇到过最棘手的数据清洗问题是什么？是隐藏空格、格式混乱，还是合并单元格？欢迎交流，共同寻找解决方案。

🎯 痛点四：海量数据中查找，犹如大海捞针

“帮我查一下工号10086对应的姓名。”——过去你可能需要在数万行中艰难搜寻。

现在，试试更强大的 XLOOKUP​，它在易用性和功能上都优于经典的 VLOOKUP：

=XLOOKUP(10086, 工号列, 姓名列, "查无此人")

✅ ​优势：

1. 无需指定列号
2. 支持向左查找
3. 可自定义查无结果时的提示，而非冷冰冰的 #N/A

​多条件查找进阶示例（例如查找“华东区产品A的价格”）：

=XLOOKUP(1, (区域列 = "华东") * (产品列 = "产品A"), 价格列)

此公式的精妙之处在于：先分别判断区域和产品条件，得到两组 TRUE/FALSE​数组，相乘后仅当两个条件同时满足时结果为 1，从而精确定位。

💡 ​动手练习：在你的数据中找一个需要多条件查找的场景，尝试使用这个“数组乘法”查找法，体验其精准与高效。

🚨 痛点五：错误值频现，报表显得不专业

​#N/A​、#DIV/0!​、#VALUE!……这些错误标志不仅影响美观，还可能降低报表的可信度。

​一个函数全面防护​：IFERROR

=IFERROR(原公式, "出现错误时希望显示的内容")

​应用示例：

=IFERROR(XLOOKUP(10086, 工号列, 姓名列), "查无此人")
=IF(上月数据 = 0, "（上月无数据）", (本月 - 上月) / 上月)

​常见错误快速诊断表：

📍 ​花一分钟​，为你报表中的核心公式穿上 IFERROR的“防护衣”，立刻提升报表的稳健性与专业度。这个习惯，值得拥有。

🧩 整合应用：构建你的自动化数据流

优秀的工具需要正确的使用流程。一个高效的 Excel 数据处理流程，可以按以下步骤搭建：

1. 建立标准化数据源

• 每列只存储一种信息（例如，省份和城市分两列）
• 每行只记录一条数据（避免使用合并单元格）
• 严格统一数据格式（日期、数值、文本等各有其规）

2. 设置数据清洗区

在独立的工作表中，运用上述清洗公式对原始数据进行预处理。​务必保留原始数据，所有清洗操作均在副本上进行。

3. 打造分析仪表板

结合 SUMIFS​、XLOOKUP​及动态日期公式，构建核心分析表格。关键指标可辅以​条件格式（例如：达成目标标绿，接近目标标黄，未达标标红），实现视觉化快速洞察。

4. 实现一键刷新

• 对数据透视表，右键选择“刷新”
• 添加切片器，实现图表与控件的联动
• 可为关键报表设置刷新按钮，一键更新所有数据

❓ 常见问题与应对策略

Q：公式确认无误，但结果错误？

A：很可能是数据类型不一致。使用 =ISNUMBER(A1)​进行检验：返回 TRUE​方为数值。文本型数字可使用 =VALUE(A1)转换。

Q：工作簿运行越来越慢？

A：尽量避免整列引用（如 A:A​），改用实际数据范围（如 A2:A1000​）。也可按 Ctrl + T将区域转换为“表格”，Excel 会自动优化范围管理。

Q：仍需每月手动粘贴新数据？

A：尝试使用【数据】→【获取与转换】→【从文件】功能。首次设置后，后续只需点击“刷新”即可导入最新数据。

Q：能否一键生成并发送报告邮件？

A：可以，这通常需要借助 VBA 宏实现。如果报告需定期发送，投入少许时间学习自动化发送将是值得的（网络上有大量成熟案例可供参考）。

💡 最后的话：做工具的主人，而非奴仆

我也曾以为 Excel 仅是电子化的表格，直到领悟它其实是​人与数据间的翻译官。

你将需求告诉它：“请分析华东区上个月产品A的销售情况。”它通过公式“翻译”给计算机，而后将清晰的结果呈现于你面前。

那些看似复杂的公式，不过是更精确的翻译指令。

​今天，不妨开启一个小改变：

1. 打开那份令你头疼的月度报表
2. 找到一个仍需手动更新日期的公式
3. 用本文的动态日期公式替换它
4. 填入下月数据，验证其自动更新

仅此一步，下个月你便能节省半小时。

此后，你或许会自然而然地着手清理数据、优化查询、美化报表……如同整理房间，从一处开始，逐渐让整个空间清爽有序。

Excel 真正的价值，不在于你记住了多少函数，而在于你通过它自动化了多少重复劳动。 省下的时间，可用于思考、成长，或享受生活——这才是技术工具应有的意义。

一、项目背景与立项动机

故事的开始

那是一个春寒料峭的夜晚，我和女友视频聊天时，她突然说："你知道吗？还有不到三个月就是我们在一起2周年了。"

我们是一对异地恋情侣，分隔在两个城市已经一年零九个月。虽然每天都会视频聊天，但距离的隔阂总是让一些情感无法完全传递。

"时间过得真快，感觉我们好像昨天才认识一样。"女友的一句话，像一颗种子，在我心里发了芽。

立项动机

• 情感连接：跨越距离的障碍，创造一个只属于我们的虚拟空间
• 惊喜准备：为5月5日的2周年纪念日准备一个特别的礼物
• 技术实践：作为前端开发者，挑战纯前端实现完整应用
• 数据隐私：珍贵的回忆只属于我们，不依赖第三方平台
• 长期价值：不仅是礼物，更是未来持续记录回忆的平台

秘密计划

我决定偷偷地开始这个项目，计划在5月5日我们相恋两周年的那天，给她一个大大的惊喜。从那天起，每天下班后，我都会躲在房间里，对着电脑敲代码，像一个正在准备神秘礼物的工匠。

现在，我正在倒计时——距离5月5日还有XX天。

二、详细的需求分析过程

功能需求梳理

基于项目的实际功能，我整理了以下需求：

技术需求梳理

• 纯前端实现：不依赖后端服务器，使用HTML5、CSS3、JavaScript
• 本地数据存储：使用localStorage持久化存储数据
• 响应式设计：适配移动设备和桌面设备
• 图片处理：使用FileReader API处理本地图片上传
• 用户体验：添加平滑动画和过渡效果，优化触摸交互

秘密数据收集

为了让网站更有意义，我开始秘密收集我们的回忆：

• 整理手机里的所有合照，从第一次见面到最近一次分别
• 记录所有重要的日期，包括相识日、第一次约会、每个月的纪念日
• 回忆我们之间的小故事，准备写成爱情故事
• 整理想对她说的话，准备添加到爱情宣言中

三、技术栈选型依据与考量

技术选型

• HTML5：构建页面结构，使用语义化标签
• CSS3：实现样式设计，包括响应式布局和动画效果
• JavaScript (ES6+)：实现交互逻辑和功能模块
• localStorage：本地数据存储，持久化保存所有数据
• FileReader API：处理本地图片上传和预览

技术栈选型图

图2：技术栈选型图 - 展示了爱情纪念网站使用的技术栈及其关系。前端技术（HTML5、CSS3、JavaScript）与浏览器API（localStorage、FileReader API、DOM API）共同支持项目的核心特性，包括响应式设计、单页应用和离线使用能力。

选型考量

为什么选择这些技术？让我用项目的实际需求来解释：

• 纯前端技术：满足数据隐私需求，所有数据存储在本地，不依赖外部服务器
• localStorage：适合存储我们的回忆数据，虽然有5MB的限制，但通过优化可以满足需求
• 响应式设计：确保女友无论是用手机还是电脑，都能完美浏览网站
• FileReader API：支持本地图片上传，不需要后端服务器处理
• 原生JavaScript：轻量高效，加载速度快，适合作为惊喜礼物

技术架构

项目采用模块化的JavaScript架构，将功能划分为多个独立模块：

• DataStorage：处理本地数据存储
• TimeCalculator：处理时间计算和显示
• timelineModule：处理时间轴功能
• photoWallModule：处理照片墙功能
• anniversaryModule：处理纪念日功能
• storyModule：处理爱情故事功能
• declarationModule：处理爱情宣言功能

项目架构图

图1：项目架构图 - 展示了爱情纪念网站的三层架构设计，包括用户界面层、模块层和数据层。模块层的各个功能模块通过DataStorage模块与本地存储进行交互，实现数据的持久化存储。

四、开发实现中的关键技术挑战及解决方案

核心功能模块

核心功能模块图

图4：核心功能模块图 - 展示了爱情纪念网站的六大核心功能模块及其详细功能特性，包括时间轴、照片墙、纪念日、爱情故事、爱情宣言和时间计算模块。

挑战1：localStorage存储限制

问题：localStorage的存储容量有限（通常为5MB），而我们有很多珍贵的照片。

解决方案：

• 实现图片压缩功能，在上传时自动调整图片大小
• 优化数据结构，减少冗余字段，最大化利用存储空间
• 使用Base64编码存储图片，确保数据完整性

实际操作：
我在代码中添加了图片压缩逻辑，将上传的图片限制在合理大小，同时保证视觉效果。这样既节省了存储空间，又提高了页面加载速度。

挑战2：时间计算的精度

问题：如何准确计算时间差，避免时区和夏令时的影响。

解决方案：

• 使用Date对象的getTime()方法获取时间戳，避免时区问题
• 实现多种时间显示模式，满足不同场景的需求
• 优化时间更新逻辑，确保实时性的同时减少性能消耗

实际操作：
我在TimeCalculator模块中实现了三种时间显示模式，并添加了实时更新功能，确保时间计算的准确性和显示的美观性。

挑战3：响应式布局的实现

问题：如何让网站在不同设备上都能完美显示。

解决方案：

• 使用CSS Grid和Flexbox实现弹性布局
• 添加媒体查询，针对不同屏幕尺寸调整样式
• 优化触摸交互，提高移动设备体验

实际操作：
我在CSS中添加了响应式设计，确保网站在手机、平板和桌面设备上都能完美显示，特别是照片墙的网格布局，在不同屏幕尺寸下都能保持美观。

挑战4：秘密开发的时间管理

问题：如何在不被女友发现的情况下，合理安排开发时间。

解决方案：

• 制定详细的开发计划，分解任务，确保在5月5日前完成
• 利用下班后的时间开发，避免占用和女友视频的时间
• 建立代码备份，确保数据安全
• 创造合理的借口，避免女友起疑心

实际操作：
我制定了详细的开发计划，每天完成一个小任务，确保项目稳步推进。同时，我会在和女友视频时，把代码编辑器最小化，切换到工作文档，避免露馅。

挑战5：用户体验的优化

问题：如何让网站的交互更流畅、更有吸引力。

解决方案：

• 添加平滑的过渡动画和转场效果
• 实现键盘导航，支持键盘操作
• 添加加载状态和错误处理
• 优化表单交互，提供即时反馈

实际操作：
我在照片预览功能中添加了平滑的过渡动画，在时间计算中添加了实时更新效果，让整个网站的交互更加流畅和有吸引力。

五、测试策略与部署计划

测试策略

1. 功能测试：逐个测试每个功能模块，确保所有功能正常工作
2. 兼容性测试：在女友使用的手机浏览器中反复测试
3. 响应式测试：确保在不同屏幕尺寸下都能完美显示
4. 性能测试：测试页面加载速度和交互流畅度
5. 数据测试：测试数据存储和读取的稳定性

开发流程图

图3：开发流程图 - 展示了爱情纪念网站从需求分析到5月5日惊喜发布的完整开发流程，包括开发阶段、准备阶段和发布阶段的各个关键步骤。

测试工具

• Chrome DevTools：调试JavaScript和CSS
• Responsive Design Mode：模拟女友的手机屏幕
• Lighthouse：分析性能和可访问性
• 手动测试：无数次地打开网站，测试所有功能

部署计划

1. 代码优化：在4月底前完成所有代码优化和bug修复
2. 数据填充：整理所有照片和回忆，填充到网站中
3. 最终测试：进行全面的功能测试和性能测试
4. 部署方式：
   • 生成最终的HTML文件，确保所有功能正常
   • 上传到云存储服务，生成一个唯一的访问链接
   • 备份所有数据，确保安全
5. 时机选择：5月5日当天，在我们视频聊天时，突然发给她

六、项目进展与未来期待

目前进展

• 核心功能开发：已完成时间轴、照片墙、纪念日、爱情故事、爱情宣言等所有核心功能
• 数据结构优化：已实现localStorage数据的高效存储和管理
• 响应式设计：已完成在不同设备上的适配
• 用户体验优化：已添加平滑动画和过渡效果
• 数据收集：正在整理和上传我们的照片和回忆

项目时间线图

图5：项目时间线图 - 展示了爱情纪念网站从2月到5月5日的详细项目时间线，包括开发、准备和发布三个阶段的里程碑。

对5月5日的期待

那一天，我会提前准备好一切，然后在视频聊天时，神秘地对她说："宝贝，我为你准备了一个特别的2周年礼物。"

当她打开链接，看到那个充满我们回忆的网站时，我想象她会：

• 看到时间轴上的第一个节点——我们第一次见面的那天
• 浏览照片墙上的合照，回忆起每一次见面的场景
• 看到纪念日模块中我们的重要日期
• 读到我为她写的爱情故事
• 看到爱情宣言中我对她的表白
• 发现时间计算器显示"我们已经在一起730天"

那一刻，距离将不再是障碍，我们的情感会通过这个网站紧紧连接在一起。

长期价值

这个网站不仅是2周年的礼物，更是我们未来持续记录回忆的平台。以后，我们可以：

• 继续在时间轴上添加新的回忆
• 在照片墙上传新的合照
• 在纪念日模块添加新的重要日期
• 续写我们的爱情故事
• 添加新的爱情宣言
• 看着时间计算器的数字不断增长

七、网站界面预览

1. 时间轴页面

描述：记录重要时刻的时间轴页面，包含时间计算和重要时刻节点。

功能：

• 时间轴节点的添加、编辑、删除
• 节点照片的上传和展示
• 里程碑标记
• 时间轴的滚动浏览
• 多种时间显示模式切换

布局：

• 顶部时间计算卡片，显示在一起的时间
• 左侧时间线，右侧节点内容
• 每个节点包含标题、日期、描述和照片
• 节点的渐入动画效果

特色：

• 实时更新的时间计算器
• 平滑的节点动画效果
• 响应式设计，适配不同设备

图6：时间轴页面 - 展示了时间计算卡片和重要时刻节点，显示了相识至今的时间和第一个节点"初识"。

2. 照片墙页面

描述：展示照片的网格布局页面，支持照片的上传和管理。

功能：

• 照片的上传、编辑和删除
• 点击照片查看大图预览
• 响应式网格布局
• 照片信息的编辑

布局：

• 自适应网格，根据屏幕尺寸调整列数
• 每张照片带有标题和日期
• 悬停效果显示操作按钮
• 上传照片按钮

特色：

• 响应式网格布局
• 平滑的悬停效果
• 大图预览功能

图7：照片墙页面 - 展示了照片墙的网格布局，包含两张示例照片，每张照片都有悬停效果。

3. 纪念日页面

描述：展示和管理纪念日的页面，支持多种类型的纪念日。

功能：

• 纪念日的添加、编辑、删除
• 自动倒计时显示
• 已过纪念日标记
• 多种纪念日类型

布局：

• 卡片式布局，每个纪念日一个卡片
• 显示倒计时或已过时间
• 分类展示不同类型的纪念日
• 添加纪念日按钮

特色：

• 实时更新的倒计时
• 已过纪念日的特殊标记
• 不同类型纪念日的颜色区分

图8：纪念日页面 - 展示了两个纪念日卡片，左侧是已过的"初识"纪念日，右侧是未来的"结婚纪念日"，显示了倒计时。

4. 爱情故事页面

描述：展示爱情故事的页面，支持故事集和章节的管理。

功能：

• 故事集的创建和管理
• 章节的添加、编辑、删除
• 故事的阅读模式
• 故事的分类管理

布局：

• 故事集列表，每个故事集一个卡片
• 故事阅读页面，包含章节导航
• 章节内容的优雅展示
• 添加故事按钮

特色：

• 故事集的卡片式布局
• 优雅的阅读体验
• 章节的有序管理

图9：爱情故事页面 - 展示了故事集列表，包含一个"测试"故事，显示了故事的创建日期、章节数和简介。

5. 爱情宣言页面

描述：展示爱情宣言的页面，支持宣言的添加和管理。

功能：

• 宣言的添加、编辑、删除
• 按分类展示
• 宣言的卡片式布局

布局：

• 卡片式布局，每个宣言一个卡片
• 分类标签筛选
• 优雅的文字展示效果
• 添加宣言按钮

特色：

• 不同风格的宣言卡片
• 分类标签的视觉区分
• 简洁优雅的布局

图10：爱情宣言页面 - 展示了两个爱情宣言卡片，左侧是粉色心形背景的"sweet"类型宣言，右侧是绿色星星背景的"romantic"类型宣言。

6. 技术实现

响应式设计：

• 使用CSS Grid和Flexbox实现响应式布局
• 媒体查询适配不同屏幕尺寸

交互效果：

• 平滑的过渡动画
• 图片懒加载
• 键盘导航支持
• 触摸优化

数据存储：

• 使用localStorage存储所有数据
• 数据结构优化
• 定期备份

7. 未来展望

功能扩展：

• 导出/导入功能
• 主题切换
• 更多交互效果

用户体验：

• 优化加载速度
• 提升交互流畅度
• 增强情感连接

结语

从构思到现在，它不仅是一个技术项目，更是一份情感的结晶。每一行代码都带着我的思念，每一个功能都藏着我的用心。

异地恋的道路虽然艰辛，但因为有了这样的小期待，有了共同的回忆空间，距离反而让我们的感情更加深厚。每当我在代码中添加一个新的功能，我都会想象女友看到时的表情，这成为了我最大的动力。

现在，我正在倒计时，等待着5月5日的到来。我相信，当女友看到这个网站时，她会明白，无论距离有多远，我的心永远和她在一起。

技术可以跨越山海，代码可以传递真情。这就是这个项目最美好的地方。

附录

项目地址：https://github.com/NoEggEgg/love-memorial-website

基于两双筷子原版插件优化，在保持稳定性的基础上增加存储路径自定义功能

之前有过一篇又拍云的，大家可以去看看：

📦 核心改进：存储路径的自定义化

1. 从预设模式到动态配置

原版插件提供了两种固定路径格式，但在实际使用中，站长们有更多样化的存储需求：

• 统一管理多个网站资源：一个多吉云账号管理多个网站
• 符合现有CDN配置规则：适应已有的CDN缓存策略
• 保持与旧系统的路径兼容：从其他平台迁移时保持路径结构
• 按内容类型分类存储：图片、文档、视频分开存放

优化后：

• ✅ 完全可配置的存储根目录
• ✅ 支持任意自定义路径结构
• ✅ 自动兼容原有配置模式
• ✅ 提供平滑的迁移路径
• ✅ 智能路径格式化处理

2. 🌟 实际应用场景

🏠 个人博客    → 使用 /uploads 简洁明了
🏢 企业网站   → 使用 /static 分类清晰
🔧 多站点管理 → 使用 /site1/uploads /site2/uploads 隔离管理
🔄 迁移用户   → 使用 /typecho/uploads 保持原路径
📊 内容平台   → 使用 /images /videos /docs 按类型分类

🔧 技术实现亮点

1. 可配置的存储目录

// 🎯 原版：固定两种模式（二选一）
if ($pluginConfig['path_style'] == 'typecho') {
    $uploadPath = self::getUploadDir().$uploadPath;
}
// 只能选择：Typecho风格 或 极简风格

// ✨ 新版：动态配置（自由定义）
$customDir = $pluginConfig['custom_dir'] ?? '/files';
$uploadPath = $customDir . '/' . $date->year . '/' . $date->month . '/' . $date->day;
// 可以填写：/uploads、/static、/typecho/uploads 等任意路径

2. 严格的输入验证

public static function configCheck($settings) {
    // 🔒 必填项检查
    if (empty($settings['custom_dir'])) {
        throw new Exception('存储目录不能为空');
    }
  
    // 📝 格式验证
    if (!str_starts_with($settings['custom_dir'], '/')) {
        throw new Exception('存储目录必须以斜杠(/)开头');
    }
  
    // 🛡️ 安全字符检查
    if (preg_match('/[<>:"|?*]/', $settings['custom_dir'])) {
        throw new Exception('存储目录包含非法字符');
    }
  
    // 📊 路径深度限制（防止过深路径）
    $depth = substr_count($settings['custom_dir'], '/') - 1;
    if ($depth > 5) {
        throw new Exception('存储目录层级过深，建议不超过5级');
    }
}

3. 📋 配置示例

# 配置：/uploads
# 实际路径：/uploads/2026/01/22/filename.jpg
# 适合：个人博客、简单站点

# 配置：/typecho/uploads  
# 实际路径：/typecho/uploads/2026/01/22/filename.jpg
# 适合：从原版升级、保持路径一致

# 配置：/static/images
# 实际路径：/static/images/2026/01/22/filename.jpg
# 适合：企业网站、资源分类

# 配置：/site/blog/uploads
# 实际路径：/site/blog/uploads/2026/01/22/filename.jpg
# 适合：多站点、子站点管理

# 配置：/
# 实际路径：/2026/01/22/filename.jpg
# 适合：极简主义、根目录存储

📂 存储路径命名指南

1. 推荐命名方案

📁 个人博客推荐：/uploads
📁 企业网站推荐：/static
📁 多站点推荐：/site/[id]/uploads
📁 Typecho老用户：/typecho/uploads
📁 资源分类推荐：/images、/docs、/videos
📁 日期优先推荐：/2026/uploads

2. ✅ 命名最佳实践

1. 使用小写字母：避免大小写敏感问题（Linux/Windows差异）
2. 使用连字符而非下划线：/my-files比 /my_files更友好
3. 保持简洁：建议不超过3级深度，便于管理
4. 语义明确：路径名能反映内容类型，便于识别
5. 避免保留字：不要使用系统保留目录名
6. 英文优先：中文路径可能在某些系统上有兼容性问题

3. ❌ 避免这样写

/files/uploads           # 重复了"uploads"，冗余
/my uploads             # 包含空格，可能引发问题
/uploads/               # 末尾不要加斜杠
/../../etc              # 危险路径，安全风险
/CONFIG                 # 全大写，不美观
/2026-01-22/files       # 包含特殊字符

🔄 从原版升级

1. 配置对应关系

如果你正在使用原版插件，升级时只需对应填写：

2. 📋 升级步骤

# 第一步：备份
1. 备份当前插件配置（截图或记录）
2. 备份重要上传文件（以防万一）

# 第二步：安装新版
1. 下载新版插件文件
2. 上传到 /usr/plugins/DogeUpload/
3. 覆盖原有文件（保留配置）

# 第三步：修改配置
1. 进入Typecho后台 → 插件管理
2. 找到DogeUpload插件，点击"设置"
3. 根据原配置填写"存储目录"
   - 原Typecho风格 → 填写：/typecho/uploads
   - 原极简风格 → 填写：/
4. 其他配置保持不变
5. 点击"保存"

# 第四步：验证测试
1. 上传一个测试文件
2. 检查文件是否出现在正确路径
3. 查看文章中图片显示是否正常

⚠️ 重要提醒

1. 已上传文件不受影响：修改存储目录仅对新上传文件生效，已存在的文件保持原路径
2. 手动迁移需要：如需统一所有文件路径，需要手动迁移并更新数据库引用
3. CDN配置同步：如果使用CDN，确保CDN回源配置支持新路径
4. 测试环境先行：建议在测试环境验证无误后再应用到生产环境
5. 路径一旦确定：尽量避免频繁修改，以免造成路径混乱

❓ 常见问题

Q：改了存储目录，旧文章的图片会失效吗？

A：不会失效。插件会保持旧图片的原始路径，只有新上传的图片使用新路径。

Q：可以随时修改存储目录吗？

A：技术上可以，但建议在访问量低时修改，修改后立即测试上传功能。

Q：填写的路径在存储桶中不存在怎么办？

A：插件会自动创建所需的目录结构，无需手动在多吉云创建。

Q：支持中文目录名吗？

A：技术上支持，但强烈建议使用英文路径，兼容性更好，不易出问题。

Q：如何查看当前文件的实际存储路径？

A：上传文件后，可以在Typecho后台的"附件管理"中查看文件路径。

Q：修改后上传失败怎么办？

A：检查：① 路径是否以/开头；② 是否包含非法字符；③ 多吉云API配置是否正确。

Q：可以设置多级目录吗？比如 /year/month/category/****？

A：目前插件自动添加年月日三级，你可以在配置中设置基础目录，如 /blog/images，最终路径会是 /blog/images/2026/01/22/。

🎯 总结

这次优化虽然改动不大，但解决了一个很实际的问题：让存储结构适应你的需求，而不是让你去适应固定的结构。

优化带来的好处：

• 对新手友好：默认/files开箱即用，无需复杂配置
• 对老用户兼容：支持原版配置无缝迁移，零学习成本
• 对专业用户灵活：完全自定义存储层级，适应各种架构
• 对未来可扩展：为更多存储策略和功能扩展打下基础

设计理念：

1. 简洁至上：一个配置项解决路径问题
2. 稳定优先：不影响已有功能，不破坏现有数据
3. 智能辅助：自动格式化路径，减少配置错误
4. 开放灵活：不限制用户的使用方式

优化虽小，但实用性强。这个改进来源于实际使用中的需求，希望能让大家的Typecho多吉云存储体验更加顺畅、灵活！

插件信息：

• 基于版本：两双筷子原版 DogeUpload
• 优化重点：存储路径自定义
• 兼容性：完全兼容原版配置和数据
• 适用场景：所有使用多吉云存储的Typecho用户

如果你在使用中遇到任何问题，或者有改进建议，欢迎交流讨论。希望这个优化能帮助到更多Typecho站长！ 🚀

温馨提示：本文操作涉及系统磁盘，请务必做好数据备份！搞砸了别来找我哭诉（虽然大概率不会搞砸）

有需要的朋友可以另外看看这篇文章：

一、前言：甲骨文的"良心"与"小气"

甲骨文云（Oracle Cloud）确实挺良心——免费套餐能开两台X86主机+ARM 4H24G配置，这配置跑个小网站、挂个爬虫、搭个梯子（咳咳，我是说科学上网学习）绰绰有余。但！是！它有个"小气"的地方：默认只给你50G硬盘（实际显示47G），而整个账户的免费额度其实是200G！

这就好比去自助餐厅，老板说"随便吃"，结果只给你个小碟子——不是不让吃，是让你多跑几趟。好在，我们可以把碟子换成大碗！

二、扩容前的"灵魂拷问"

在动手前，先问自己三个问题：

1. 数据重要吗？ 如果只是测试环境，直接重开实例改硬盘大小最省事（但环境得重配）
2. 懒吗？ 如果懒得重装环境，那就跟着本文走扩容路线
3. 会备份吗？ 不会？现在就去学！别等数据丢了才后悔

三、方法一：后台修改引导卷（最安全）

这是官方推荐的方式，适合手残党（比如我）。

操作步骤（手把手版）

1. 登录甲骨文云后台 → 菜单 → 计算 → 实例
2. 找到你的小鸡（实例），点进去
3. 找到"引导卷" ，点"编辑"
4. 输入新大小（最大200G，别贪心）
5. 保存 → 等待状态变成"可用"

系统识别新容量

多数系统重启后会自动识别。如果没反应，别慌，试试以下命令（以Oracle Linux为例）：

# 先设置语言环境（避免乱码）
LANG=en_US.UTF-8

# 执行扩容命令
/usr/libexec/oci-growfs

# 查看磁盘大小
lsblk

如果看到 sda从50G变成了你设置的大小，恭喜你，扩容成功！

四、方法二：其他系统的"骚操作"

如果你用的不是Oracle Linux，可能需要手动操作。这里以Debian为例：

Debian系统扩容

甲骨文自带的Debian系统会提示你执行以下命令：

# 第一步：执行dd命令（别问为什么，照做就行）
sudo dd iflag=direct if=/dev/oracleoci/oraclevda of=/dev/null count=1

# 第二步：重新扫描磁盘
echo "1" | sudo tee /sys/class/block/`readlink /dev/oracleoci/oraclevda | cut -d'/' -f 2`/device/rescan

其他系统（如Ubuntu、CentOS）

执行完DD命令后，用 lsblk或 df -h查看盘符。假设你的系统盘是 sda1，执行：

# 调整文件系统大小
resize2fs /dev/sda1

注意：有些系统重启后直接 resize2fs就能完成，有些需要先执行上面的DD命令。建议先重启试试，不行再上命令。

五、常见翻车现场与自救指南

六、总结与吐槽

1. 为什么默认50G？ 我猜甲骨文是为了防止用户滥用，毕竟200G免费额度对个人来说挺香的
2. 扩容有风险吗？ 理论上风险很低，但任何磁盘操作都有万分之一的风险，所以备份！备份！备份！
3. 需要重启吗？ 多数情况需要，但有些系统（如Oracle Linux）可以在线扩容
4. 能缩容吗？ 不能！硬盘只能增不能减，就像我的体重一样

最后，如果你扩容成功了，记得在评论区留个"已成功"，让我知道这篇教程没坑人。如果翻车了...呃，建议先看备份教程。

免责声明：本文仅作技术分享，操作前请自行评估风险。作者不对任何数据丢失负责（毕竟我提醒过你备份了）。

‍

"在数字世界里，时间可以同步，但你的头发可能永远不会再同步了"

之前有过一篇简要的文章，大家可以先看看

📅 开篇：一个关于"时间旅行"的真实故事

　　最近，公司遇到一个案例："数据库主从同步延迟 10 分钟"。在大家努力排查半小时后，我们发现了一个令人哭笑不得的事实——从库服务器的时间比主库快了整整 10 分钟。是的，这台服务器正在"穿越"到未来，而我们的数据还在过去徘徊。

　　这让我想一句经典名言："服务器的时间可以不准，但你的排查思路必须准"。

　　今天，我们就来聊聊甲骨文云（Oracle Cloud）Ubuntu 系统的时间同步——这个看似简单，却能让无数运维人深夜加班的"小问题"。

🎯 一、为什么时间同步如此重要？（不只是"对个表"那么简单）

　　在分布式系统中，时间同步不是"可有可无"的装饰品，而是基础设施的基石。想象一下：

• 🔄 数据库主从复制：时间不同步可能导致数据冲突、复制中断
• 📊 日志分析：跨服务器日志时间戳错乱，排查问题如同大海捞针
• 🔐 证书验证：SSL/TLS 证书依赖时间，偏差过大直接导致服务不可用
• 🚨 监控告警：告警时间错乱，你永远不知道问题到底发生在"昨天"还是"明天"

💡 真实案例：某电商公司"双 11"大促期间，由于负载均衡器时间偏差 5 分钟，导致大量用户会话提前失效，直接损失订单数百万元。

　　用一句话总结：时间不同步，系统就变成了"薛定谔的猫"——你永远不知道它现在处于什么状态。

🧰 二、甲骨文 Ubuntu 的时间同步"工具箱"

2.1 默认配置：systemd-timesyncd（你的"贴心小助手"）

　　Ubuntu 16.04 之后，systemd-timesyncd 成为默认的时间同步服务。它就像那个"默默无闻但很靠谱"的同事——平时不声不响，但工作从不掉链子。

# 检查状态（看看这位同事今天状态如何）
timedatectl status

　　输出示例：

Local time: 一 2026-01-19 10:30:00 CST
           Universal time: 一 2026-01-19 02:30:00 UTC
                 RTC time: 一 2026-01-19 02:30:00
                Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes     ← 关键指标：同步状态
              NTP service: active  ← 关键指标：服务状态
          RTC in local TZ: no

　　如果看到 System clock synchronized: no ，别慌，先问问它："兄弟，你还好吗？"

# 查看详细服务状态
systemctl status systemd-timesyncd

2.2 进阶选择：chrony（时间同步界的"瑞士军刀"）

　　如果你对时间精度有"强迫症"（比如金融交易系统要求毫秒级同步），或者 systemd-timesyncd"罢工"了，chrony 是你的不二之选。

　　安装 chrony（给系统换个"时间管家"）：

sudo apt update && sudo apt install chrony

　　配置 NTP 服务器（告诉 chrony 该找谁对表）：

sudo nano /etc/chrony/chrony.conf

　　在甲骨文云中，有个"秘密武器"——实例元数据服务（169.254.169.254），这是云平台内部的高精度时间源：

# 添加这行到配置文件
server 169.254.169.254 iburst prefer

🎯 专业提示：iburst 参数表示初始同步时会发送多个请求快速同步，prefer 表示优先使用这个服务器。

　　重启并检查（看看新管家工作得怎么样）：

sudo systemctl restart chrony
chronyc sources -v

　　输出中的 ^* 标记表示当前同步的源。如果没有看到 ^*，嗯...可能需要请这位"管家"喝杯咖啡（重启服务）或者换个"管家"（检查配置）。

🔧 三、甲骨文云的特殊"彩蛋"与坑点

3.1 默认时间源：169.254.169.254（不是 IP，是"爱的号码牌"）

　　甲骨文云实例默认从 169.254.169.254 获取时间。这个 IP 是实例元数据服务的地址，不是公网 NTP 服务器。好处多多：

　　但要注意：这个服务只在云实例内部可用。如果你在本地环境测试，或者需要其他 NTP 服务器，需要手动配置。

3.2 防火墙：别让"门卫"拦住了时间

　　时间同步使用 UDP 123 端口。如果发现时间不同步，先检查这三道"门"：

# 第一道门：系统防火墙
sudo ufw status
# 如果启用了ufw，确保有：
# 123/udp                     ALLOW       Anywhere

# 第二道门：安全组规则（甲骨文云控制台）
# 检查出站规则：是否允许UDP 123端口

# 第三道门：网络ACL
# 甲骨文云网络ACL：确保出站流量允许

　　记住：时间同步是"单向"的——客户端主动请求服务器，所以只需要出站规则。别把防火墙配置成"只进不出"，那样时间就真的"停滞"了。

🚑 四、实战：当时间开始"穿越"时，如何优雅地修复

🆘 场景 1：时间偏差过大（超过 5 分钟）

　　症状：timedatectl status 显示 System clock synchronized: no

　　修复步骤（急救三部曲）：

1. 🚨 临时同步（先救急）：

# 先停用自动同步
sudo timedatectl set-ntp false

# 手动同步（紧急止血）
sudo ntpdate -u pool.ntp.org

# 重新启用自动同步
sudo timedatectl set-ntp true

2. 🔍 检查服务状态：

# 查看服务状态
systemctl status systemd-timesyncd

# 查看最近日志（重点看错误信息）
journalctl -u systemd-timesyncd --since "5 minutes ago" | tail -20

3. 🔄 如果持续不同步，考虑切换到 chrony：

# 优雅切换：先停用旧的，再启用新的
sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd

sudo apt install chrony -y
sudo systemctl enable --now chrony

# 配置甲骨文云专用NTP
echo "server 169.254.169.254 iburst prefer" | sudo tee -a /etc/chrony/chrony.conf
sudo systemctl restart chrony

🕐 场景 2：时区设置错误（人在上海，心在 UTC）

　　症状：时间显示正确，但时区是 UTC 或其他时区，日志时间戳让人困惑。

　　修复：

# 查看所有可用时区（找找你所在的城市）
timedatectl list-timezones | grep -i shanghai

# 设置时区（以上海为例）
sudo timedatectl set-timezone Asia/Shanghai

# 验证设置
date

💡 小贴士：生产环境建议统一使用 UTC 时区，避免时区转换带来的混乱。应用层根据业务需求显示本地时间。这样做的优点：

1. 避免夏令时问题
2. 日志时间统一
3. 跨时区协作更方便

🧪 五、高级话题：chrony 的"黑科技"调优

　　如果你对时间同步有极致追求，chrony 提供了更多"调优"选项：

5.1 调整同步策略（"温柔"还是"强硬"，你说了算）

　　在 /etc/chrony/chrony.conf 中，可以配置不同的同步策略：

# 方案A：更激进的同步策略（适合网络不稳定的环境）
maxchange 1000 0  # 允许更大的时间跳变
makestep 1 3      # 如果偏差超过1秒，立即步进调整

# 方案B：更保守的策略（适合对时间敏感的应用）
maxpoll 12        # 最大轮询间隔（4096秒）
minpoll 6         # 最小轮询间隔（64秒）

　　参数解释：

• maxchange：允许的最大时间调整量
• makestep：时间偏差超过阈值时是否"跳变"
• maxpoll/minpoll：轮询间隔，值越大同步频率越低

5.2 监控和诊断（"把脉"时间同步）

# 查看详细的同步状态
chronyc tracking

　　输出示例：

Reference ID    : C0A80101 (169.254.169.254)
Stratum         : 3
Ref time (UTC)  : Mon Jan 19 02:30:00 2026
System time     : 0.000123 seconds fast of NTP time
Last offset     : +0.000045 seconds
RMS offset      : 0.000078 seconds
Frequency       : 1.234 ppm fast
Residual freq   : +0.001 ppm
Skew            : 0.123 ppm
Root delay      : 0.012345 seconds
Root dispersion : 0.023456 seconds
Update interval : 64.2 seconds
Leap status     : Normal

📊 看懂关键指标：

• System time：正数表示系统时间快了，负数表示慢了
• Last offset：最近一次同步的偏移量
• Stratum：时间源层级，数字越小越接近源头
• 理想状态：offset < 1ms，stratum ≤ 5

5.3 可视化监控（Grafana 看板）

　　如果需要更直观的监控，可以配置 Prometheus+Grafana 监控时间偏移：

# node_exporter的textfile收集器配置
# 创建收集脚本
cat > /usr/local/bin/ntp_offset.sh << 'EOF'
#!/bin/bash
offset=$(chronyc tracking | grep 'System time' | awk '{print $4}')
echo "ntp_offset" $offset
EOF

# 添加到crontab每分钟执行
echo "* * * * * /usr/local/bin/ntp_offset.sh > /var/lib/node_exporter/ntp_offset.prom" | sudo tee -a /etc/crontab

🎓 六、总结：时间同步的"哲学"与最佳实践

　　时间同步看似简单，实则暗藏玄机。经过多年的"血泪教训"，我总结了几个关键点：

🏆 最佳实践清单

1. ✅ 默认配置通常够用：甲骨文 Ubuntu 的 systemd-timesyncd + 169.254.169.254，99% 的场景无需折腾
2. ✅ 问题排查有顺序：先检查服务状态 → 查看日志 → 检查网络 → 考虑切换服务
3. ✅ 时区设置要统一：生产环境建议 UTC，避免"时区地狱"
4. ✅ 监控不能少：配置监控告警，及时发现时间偏差
5. ✅ 文档要记录：记录每台服务器的时间同步配置，便于排查

📈 性能指标参考