1. 糟糕的开头
我当场裂开。今天早上刚把咖啡端到桌子上，习惯性打开 Google Search Console，结果满屏的红字报警：tools.daima.life 的 404 错误像心电图断气一样狂飙。那一刻我才意识到，自己这个“资深极客”在大意之下捅了马孵窝——我把项目从子域名迁到了根域名，却忘了旧链接里那堆积攒了三年的权重。看着好不容易磨出来的 SEO 排名缩水，我心跳比 MacBook Pro 的风扇转速还快。这要是处理不好，我这 daima.life 工具箱就直接在互联网赛博空间里“查无此站”了。
2. 我的思考
为什么非要折腾迁移？道理很简单，根域名的收录权重在 2026 年依然是“真香”定律，我想让用户直接敲 daima.life 就能秒开工具。但市面上那些笨重的方案方案，比如在服务器上搓个 Nginx 反代，或者用那种慢得要死的 JS 跳转，我直接 PASS。
daima.life 的架构底色是 Privacy-First 和 Client-side Only，我绝对不能允许为了个重定向就让响应时间增加几十毫秒。我需要的是在 Cloudflare 边缘节点直接完成“降维打击”，在请求还没碰到我的 Pages 容器之前，就把它精准导航到新家。
3. 技术硬核区
我最后没有选择过时的 Page Rules，而是利用了 Cloudflare 2026 年最好用的 Redirect Rules (Dynamic)。这玩意的核心在于它的过滤器引擎（Filter Engine），它允许我用类似于逻辑表达式的方式，把老域名的路径原封不动地搬到新域名。
// 核心逻辑伪代码：边缘侧重定向逻辑
if (http.host eq "tools.daima.life") {
// 提取当前路径，例如 /tools/runjs
let current_path = http.request.uri.path;
// 提取查询参数，例如 ?code=print(1)
let query_string = http.request.uri.query;
// 执行 301 永久重定向到根域名
redirect_to(
status: 301,
url: concat("https://daima.life", current_path, "?", query_string)
);
}实际操作中，我在 Cloudflare Dashboard 搓了一个动态规则。特别注意：我用了 wildcard 匹配来处理那些带后缀的资源，确保 tools.daima.life/favicon.ico 也能瞬间飞到它该去的地方。最绝的是，这整套逻辑在边缘节点的执行时间是 0.2ms。格局瞬间打开，这就是性能强迫症的顶级快乐。
4. FAQ 模块
Q1: 为什么不用 302 临时重定向，而非要死磕 301？
A: 兄弟，301 是告诉搜索引擎“我搬家了，老房子的地契（权重）全转给新房子”。如果你用 302，搜索蜘蛛会觉得你只是出来旅游，权重根本转不过去。在 2026 年，SEO 算法比你女朋友还敏感，选错状态码直接让你凉凉。
Q2: 这种边缘重定向对 HSTS 预加载有影响吗？
A: 没毛病，这正是我想说的。我在老域名上依然维持了浏览器级别的强制 HTTPS。Cloudflare Rules 运行在 TLS 握手之后，它会带着我们的安全头一起飞，安全感直接拉满。
Q3: 遇到带参数的深度链接（Deep Links）会失效吗？
A: 不可能。我的规则里强制开启了 Preserve Query String。无论用户是通过三年前的旧博客链接点进来的，还是通过微信收藏夹，参数一个都不会丢。
5. 结尾
代码推上去的那一刻，看着 Search Console 的曲线开始平滑过渡到新域名，我长舒了一口气。目前的 Redirect Rules 虽然强，但我已经在调研 Cloudflare 新出的 Wasm-runtime Snippets 了，也许下一次迁移，我能直接在边缘侧实现基于 AI 的语义路径自动纠错。你要不要也来 daima.life 感受一下这种“无感跳转”的丝滑？