前言

我最近完成了一项“大工程”：将个人博客从传统的 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 引入的生产级工程技能！

需求到发布完整链路

graph LR
    A[idea-refine] --> B[spec-driven-development]
    B --> C[planning-and-task-breakdown]
    C --> D[incremental-implementation]
    D --> E[test-driven-development]
    E --> F[code-review-and-quality]
    F --> G[shipping-and-launch]

📊 数据处理 (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个)

四、配置文件结构

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

[collapse status=“false” title=“配置文件（完整版）"]这里编辑收缩框内容

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/

[/collapse]

五、技能更新管理

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

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投诉等法律手段时，请确保你拥有相关内容的完整版权。技术拦截手段请确保不误伤真实用户和合法搜索引擎爬虫。

[collapse status=“false” title=“太长了，折叠一下，需要的自行点开”]

模板一：DMCA侵权下架通知（主机商/注册商）

发送对象：abuse@主机商域名 + abuse@注册商域名
抄送：自己的邮箱（备份）
预期时效：24-72小时
跟进策略：48小时无回复则再次发送，并抄送上级部门（如legal@或support@）

英文版 / English Version

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

中文版 / Chinese Version

主题：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

模板二：Google AdSense政策违规举报

发送渠道：AdSense政策中心
举报类型：Copyright infringement / Scraped content（版权侵权/抓取内容）

英文版 / English Version

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

中文版 / Chinese Version

主题：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结果

模板三：Cloudflare Abuse投诉

发送渠道：Cloudflare Abuse表单
表单选择：Copyright infringement & DMCA violations

英文版 / English Version

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

中文版 / Chinese Version

主题：滥用投诉 - 通过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

[/collapse]

使用建议

💡 关键提示：

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图标库

让图标管理变得简单

有以下特点😂：

• ✅ 显示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代码，干扰了事件监听器的绑定，导致事件处理函数无法正常触发。

[collapse status=“false” title=“解决思路”]

解决思路：

• 使用捕获阶段的事件监听器，避免事件冒泡被干扰
• 实现双重初始化机制，确保代码在各种情况下都能正确初始化
• 增强DOM元素检查，添加元素存在性检查和重试机制

代码示例：

// 使用捕获阶段的事件监听器
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);
})();

[/collapse]

2. ARIA可访问性问题

问题表现：浏览器控制台报ARIA可访问性错误，提示"Blocked aria-hidden on an element because its descendant retained focus"，影响网站的可访问性评分。

技术原因：当关闭模态框时，模态框中的按钮仍然保持焦点，而模态框被设置为aria-hidden=“true”，违反了WAI-ARIA规范，因为辅助技术不应该将焦点隐藏在用户看不到的元素上。

[collapse status=“false” title=“解决思路”]

解决思路：

• 在关闭模态框之前，检查当前获得焦点的元素是否在模态框内
• 如果焦点在模态框内，将焦点移到页面主体
• 先处理焦点，再设置aria-hidden=“true”

代码示例：

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);
},

[/collapse]

3. 字体加载问题

问题表现：网站加载时，浏览器控制台显示字体加载失败的错误，提示"Failed to load resource: net::ERR_CONNECTION_CLOSED"。

技术原因：使用的国内一些字体库连接不稳定，导致字体无法正常加载，影响网站的视觉效果。

[collapse status=“false” title=“解决思路”]

解决思路：

• 尝试使用其他国内字体源，如百度字体库、360字体库、字节跳动
• 最终选择使用Google Fonts官方CDN，虽然在国内可能有一些延迟，但稳定性更高

代码示例：

<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">

[/collapse]

4. 表单重复提交问题

问题表现：用户提交表单后刷新页面，会导致表单重复提交，可能造成重复数据或其他意外行为。

技术原因：传统的表单提交方式会在页面刷新时重新发送请求，导致重复提交。

[collapse status=“false” title=“解决思路”]

解决思路：

• 实现PRG（Post-Redirect-Get）模式
• 使用会话存储消息，重定向后显示
• 确保表单提交后不会因为刷新而重复提交

代码示例：

if ($successCount > 0) {
    $_SESSION['message'] = '成功添加 ' . $successCount . ' 个SVG图标！';
    // 重定向到同一个页面，防止重复提交
    header('Location: ' . $_SERVER['PHP_SELF']);
    exit;
}

[/collapse]

结语

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.
   选择国家/地区 ，输入您的电子邮件地址 ，然后开始聊天。

具体地址是：https://docs.oracle.com/en-us/iaas/Content/GSG/Tasks/signinginIdentityDomain.htm#faq_how_do_i_contact_support

以上，诸君共勉~

什么是“萌国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：处理本地图片上传和预览

技术栈选型图

graph LR
    subgraph 前端技术
        HTML5[HTML5\n页面结构]
        CSS3[CSS3\n样式设计]
        JS[JavaScript\n交互逻辑]
    end
  
    subgraph 浏览器API
        LS[localStorage\n本地存储]
        FR[FileReader API\n文件读取]
        DOM[DOM API\n文档操作]
    end
  
    subgraph 项目特性
        RWD[响应式设计]
        SPA[单页应用]
        Offline[离线使用]
    end
  
    HTML5 --> RWD
    CSS3 --> RWD
    JS --> SPA
    JS --> Offline
    LS --> Offline
    LS --> SPA
    FR --> SPA
    DOM --> SPA
  
    classDef frontend fill:#f9f,stroke:#333,stroke-width:2px
    classDef api fill:#bbf,stroke:#333,stroke-width:2px
    classDef feature fill:#bfb,stroke:#333,stroke-width:2px
  
    class HTML5,CSS3,JS frontend
    class LS,FR,DOM api
    class RWD,SPA,Offline feature

图2：技术栈选型图 - 展示了爱情纪念网站使用的技术栈及其关系。前端技术（HTML5、CSS3、JavaScript）与浏览器API（localStorage、FileReader API、DOM API）共同支持项目的核心特性，包括响应式设计、单页应用和离线使用能力。

选型考量

为什么选择这些技术？让我用项目的实际需求来解释：

• 纯前端技术：满足数据隐私需求，所有数据存储在本地，不依赖外部服务器
• localStorage：适合存储我们的回忆数据，虽然有5MB的限制，但通过优化可以满足需求
• 响应式设计：确保女友无论是用手机还是电脑，都能完美浏览网站
• FileReader API：支持本地图片上传，不需要后端服务器处理
• 原生JavaScript：轻量高效，加载速度快，适合作为惊喜礼物

技术架构

项目采用模块化的JavaScript架构，将功能划分为多个独立模块：

• DataStorage：处理本地数据存储
• TimeCalculator：处理时间计算和显示
• timelineModule：处理时间轴功能
• photoWallModule：处理照片墙功能
• anniversaryModule：处理纪念日功能
• storyModule：处理爱情故事功能
• declarationModule：处理爱情宣言功能

项目架构图

graph TD
    subgraph 用户界面层
        UI[用户界面]
    end
  
    subgraph 模块层
        TM[timelineModule\n时间轴模块]
        PTM[photoWallModule\n照片墙模块]
        AM[anniversaryModule\n纪念日模块]
        SM[storyModule\n爱情故事模块]
        DM[declarationModule\n爱情宣言模块]
        TC[TimeCalculator\n时间计算模块]
    end
  
    subgraph 数据层
        DS[DataStorage\n数据存储模块]
        LS[localStorage\n本地存储]
    end
  
    UI --> TM
    UI --> PTM
    UI --> AM
    UI --> SM
    UI --> DM
    UI --> TC
  
    TM --> DS
    PTM --> DS
    AM --> DS
    SM --> DS
    DM --> DS
    TC --> DS
  
    DS --> LS
    LS --> DS
  
    classDef ui fill:#f9f,stroke:#333,stroke-width:2px
    classDef module fill:#bbf,stroke:#333,stroke-width:2px
    classDef data fill:#bfb,stroke:#333,stroke-width:2px
  
    class UI ui
    class TM,PTM,AM,SM,DM,TC module
    class DS,LS data

图1：项目架构图 - 展示了爱情纪念网站的三层架构设计，包括用户界面层、模块层和数据层。模块层的各个功能模块通过DataStorage模块与本地存储进行交互，实现数据的持久化存储。

四、开发实现中的关键技术挑战及解决方案

核心功能模块

核心功能模块图

graph TD
    subgraph 核心功能模块
        TM[timelineModule\n时间轴模块]
        PTM[photoWallModule\n照片墙模块]
        AM[anniversaryModule\n纪念日模块]
        SM[storyModule\n爱情故事模块]
        DM[declarationModule\n爱情宣言模块]
        TC[TimeCalculator\n时间计算模块]
    end
  
    subgraph 功能特性
        TM1[添加/编辑/删除节点]
        TM2[照片上传]
        TM3[里程碑标记]
      
        PTM1[本地图片上传]
        PTM2[照片管理]
        PTM3[大图预览]
      
        AM1[多种纪念日类型]
        AM2[自动倒计时]
        AM3[已过纪念日标记]
      
        SM1[创建故事集]
        SM2[章节管理]
        SM3[故事阅读]
      
        DM1[添加宣言]
        DM2[分类展示]
        DM3[编辑删除]
      
        TC1[多种时间显示模式]
        TC2[实时更新]
        TC3[里程碑切换]
    end
  
    TM --> TM1
    TM --> TM2
    TM --> TM3
  
    PTM --> PTM1
    PTM --> PTM2
    PTM --> PTM3
  
    AM --> AM1
    AM --> AM2
    AM --> AM3
  
    SM --> SM1
    SM --> SM2
    SM --> SM3
  
    DM --> DM1
    DM --> DM2
    DM --> DM3
  
    TC --> TC1
    TC --> TC2
    TC --> TC3
  
    classDef module fill:#f9f,stroke:#333,stroke-width:2px
    classDef feature fill:#bbf,stroke:#333,stroke-width:2px
  
    class TM,PTM,AM,SM,DM,TC module
    class TM1,TM2,TM3,PTM1,PTM2,PTM3,AM1,AM2,AM3,SM1,SM2,SM3,DM1,DM2,DM3,TC1,TC2,TC3 feature

图4：核心功能模块图 - 展示了爱情纪念网站的六大核心功能模块及其详细功能特性，包括时间轴、照片墙、纪念日、爱情故事、爱情宣言和时间计算模块。

挑战1：localStorage存储限制

问题：localStorage的存储容量有限（通常为5MB），而我们有很多珍贵的照片。

解决方案：

• 实现图片压缩功能，在上传时自动调整图片大小
• 优化数据结构，减少冗余字段，最大化利用存储空间
• 使用Base64编码存储图片，确保数据完整性

实际操作：
我在代码中添加了图片压缩逻辑，将上传的图片限制在合理大小，同时保证视觉效果。这样既节省了存储空间，又提高了页面加载速度。

挑战2：时间计算的精度

问题：如何准确计算时间差，避免时区和夏令时的影响。

解决方案：

• 使用Date对象的getTime()方法获取时间戳，避免时区问题
• 实现多种时间显示模式，满足不同场景的需求
• 优化时间更新逻辑，确保实时性的同时减少性能消耗

实际操作：
我在TimeCalculator模块中实现了三种时间显示模式，并添加了实时更新功能，确保时间计算的准确性和显示的美观性。

挑战3：响应式布局的实现

问题：如何让网站在不同设备上都能完美显示。

解决方案：

• 使用CSS Grid和Flexbox实现弹性布局
• 添加媒体查询，针对不同屏幕尺寸调整样式
• 优化触摸交互，提高移动设备体验

实际操作：
我在CSS中添加了响应式设计，确保网站在手机、平板和桌面设备上都能完美显示，特别是照片墙的网格布局，在不同屏幕尺寸下都能保持美观。

挑战4：秘密开发的时间管理

问题：如何在不被女友发现的情况下，合理安排开发时间。

解决方案：

• 制定详细的开发计划，分解任务，确保在5月5日前完成
• 利用下班后的时间开发，避免占用和女友视频的时间
• 建立代码备份，确保数据安全
• 创造合理的借口，避免女友起疑心

实际操作：
我制定了详细的开发计划，每天完成一个小任务，确保项目稳步推进。同时，我会在和女友视频时，把代码编辑器最小化，切换到工作文档，避免露馅。

挑战5：用户体验的优化

问题：如何让网站的交互更流畅、更有吸引力。

解决方案：

• 添加平滑的过渡动画和转场效果
• 实现键盘导航，支持键盘操作
• 添加加载状态和错误处理
• 优化表单交互，提供即时反馈

实际操作：
我在照片预览功能中添加了平滑的过渡动画，在时间计算中添加了实时更新效果，让整个网站的交互更加流畅和有吸引力。

五、测试策略与部署计划

测试策略

1. 功能测试：逐个测试每个功能模块，确保所有功能正常工作
2. 兼容性测试：在女友使用的手机浏览器中反复测试
3. 响应式测试：确保在不同屏幕尺寸下都能完美显示
4. 性能测试：测试页面加载速度和交互流畅度
5. 数据测试：测试数据存储和读取的稳定性

开发流程图

graph TD
    A[需求分析\n情感+技术]
    B[技术选型\n纯前端方案]
    C[架构设计\n模块化架构]
    D[核心功能开发\n六大模块]
    E[技术挑战解决\n存储+时间+响应式]
    F[测试优化\n兼容性+性能]
    G[数据填充\n回忆收集]
    H[部署准备\n云存储链接]
    I[5月5日\n惊喜发布]
  
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I
  
    subgraph 开发阶段
        A
        B
        C
        D
        E
        F
    end
  
    subgraph 准备阶段
        G
        H
    end
  
    subgraph 发布阶段
        I
    end
  
    classDef dev fill:#f9f,stroke:#333,stroke-width:2px
    classDef prep fill:#bbf,stroke:#333,stroke-width:2px
    classDef pub fill:#bfb,stroke:#333,stroke-width:2px
  
    class A,B,C,D,E,F dev
    class G,H prep
    class I pub

图3：开发流程图 - 展示了爱情纪念网站从需求分析到5月5日惊喜发布的完整开发流程，包括开发阶段、准备阶段和发布阶段的各个关键步骤。

测试工具

• Chrome DevTools：调试JavaScript和CSS
• Responsive Design Mode：模拟女友的手机屏幕
• Lighthouse：分析性能和可访问性
• 手动测试：无数次地打开网站，测试所有功能

部署计划

1. 代码优化：在4月底前完成所有代码优化和bug修复
2. 数据填充：整理所有照片和回忆，填充到网站中
3. 最终测试：进行全面的功能测试和性能测试
4. 部署方式：
   • 生成最终的HTML文件，确保所有功能正常
   • 上传到云存储服务，生成一个唯一的访问链接
   • 备份所有数据，确保安全
5. 时机选择：5月5日当天，在我们视频聊天时，突然发给她

六、项目进展与未来期待

目前进展

• 核心功能开发：已完成时间轴、照片墙、纪念日、爱情故事、爱情宣言等所有核心功能
• 数据结构优化：已实现localStorage数据的高效存储和管理
• 响应式设计：已完成在不同设备上的适配
• 用户体验优化：已添加平滑动画和过渡效果
• 数据收集：正在整理和上传我们的照片和回忆

项目时间线图

gantt
    title 爱情纪念网站项目时间线
    dateFormat  YYYY-MM-DD
    section 开发阶段
    需求分析           :active, des1, 2026-02-01, 7d
    技术选型与架构设计  :des2, after des1, 5d
    核心功能开发        :des3, after des2, 20d
    技术挑战解决        :des4, after des3, 10d
    测试优化           :des5, after des4, 10d
    section 准备阶段
    数据填充与整理      :prep1, after des5, 15d
    部署准备与测试      :prep2, after prep1, 5d
    section 发布阶段
    5月5日 2周年惊喜发布 :pub1, 2026-05-05, 1d
  
    section 里程碑
    项目启动           :milestone, m1, 2026-02-01, 0d
    核心功能完成        :milestone, m2, 2026-03-05, 0d
    测试完成           :milestone, m3, 2026-03-25, 0d
    数据准备完成        :milestone, m4, 2026-04-10, 0d
    部署准备完成        :milestone, m5, 2026-04-15, 0d
    惊喜发布           :milestone, m6, 2026-05-05, 0d

图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

基于两双筷子原版插件优化，在保持稳定性的基础上增加存储路径自定义功能

之前有过一篇又拍云的，大家可以去看看：

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

📦 核心改进：存储路径的自定义化

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站长！ 🚀