保哥笔记

JS判断移动端并自动跳转至m子域：iPadOS假桌面、Client Hints与SEO最佳实践

把 PC 站和手机站拆成两个域名（典型如主站 zhangwenbao.com 配 m.zhangwenbao.com）这件事，2010 年前后是行业默认方案，到 2026 年已经少有新项目这么玩了。但保哥手里仍有一批老站靠着 m. 子域跑了七八年，从 SEO 排名到老用户书签都跟它绑定，要一刀切迁到响应式既不现实也不明智。这种"已经存在的双站"才是这篇文章要解决的真实场景：一段在浏览器层面把移动设备访客自动送到 m 站的判断脚本，并且要把跳转里的细节——保留路径、避免循环、和 SEO 协调——一次说清。

下文给的两段 JS 是大多数教程都会照抄的那两段：基于 navigator.platform 的 OS 数组匹配、基于 navigator.userAgent 的关键词正则。它们能跑，但都写在 2014 年前后，对今天的 iPadOS、HarmonyOS、Edge on Mobile 都有盲区。保哥把这两段保留作为"参照实现"，重点是后面附上的实战版：能保留路径、能记忆用户在 PC 站点的"留在桌面版"选择、能避开 Googlebot Smartphone 误识别、能配合服务端 Vary: User-Agent 不被中间 CDN 缓存串站。

双站架构在 2026 年还有人用，但要先承认它的代价

响应式设计成为主流之后，m. 子域路线被业内基本判了"反模式"。Google 在 2015 年的 Mobile-Friendly Update、2018 年的 Mobile-First Indexing、2021 年的 Page Experience 全部是把 PC 与 Mobile 视作"同一份内容的不同表现"来打分的，而双站架构强行把两份"几乎一样但又有微小差异"的页面摆在两个 URL 上，等于给 Googlebot 出难题：要靠 rel="canonical"（在 m 页面指向 PC 页面）和 rel="alternate" media="..."（在 PC 页面指向 m 页面）这一对标签来声明"这两个 URL 是配对的同一篇内容"。任何一边漏配或写错域名，都会立刻引来权重稀释、收录混乱、甚至被判重复内容。

那为什么还有项目维持双站？保哥见过的真实理由有四种：第一种是历史遗产，已经积累了大量外链指向 m. 子域，全切走会断链；第二种是 m 站使用了完全不同的后端模板（比如老 PC 站用 ASP，m 站重写为 PHP），代码池都不同，迁到响应式相当于重写整个站；第三种是 m 站做了"瘦身版本"，只保留了核心内容、剥离了广告位、加载了几款专门的轻量化静态资源，业务团队评估出"双站维护成本 < 改造成本"；第四种最隐蔽——主站套了一层闭源主题，源代码丢失或者商业授权不允许深度改造，做不到响应式。

认清这四种诱因之后，再来谈"自动跳转"才有意义。下面所有写法都假设你确实需要一个 m 站，并且需要在 PC 域接收到的移动设备访问被妥当地引到 m 站。

三条检测路线的实战对比：哪一条最值得选

把"判断当前访客是不是移动设备"这件事拆开看，可选的实现路径远比早年多。保哥把目前还在生产里见过的方案归并为五条，每条的盲区都不一样：

路线一：navigator.platform 字符串匹配

原文里的第一段脚本就是这条路线，把 iPhone / iPod / iPad / android / Nokia / SymbianOS / Windows Phone 等关键词组成一个数组，循环匹配 navigator.platform。它的问题在 2026 年很明显：

结论：navigator.platform 本来就不是为设备路由设计的字段，它的目的是声明"运行 JavaScript 的宿主操作系统"，能不能被当成 UA 嗅探的输入，本来就不是它的责任。建议只把它作为辅助，不要作为主判定依据。

路线二：navigator.userAgent 正则匹配

原文里第二段那一行 /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) 是 jQuery Mobile、Bootstrap 早期版本、还有现在大量国内 CMS 的伪移动适配脚本里写法的源头。它比 platform 路线靠谱一些，因为 userAgent 是浏览器历来更愿意维护的字段。但仍然要踩这些坑：

保哥实际生产中维护的最小可用 UA 正则，是这一条：

/Android|webOS|iPhone|iPod|BlackBerry|IEMobile|Opera Mini|HarmonyOS|EdgA|EdgiOS|UCBrowser|MQQBrowser|Quark|MicroMessenger.+Mobile/i

注意 iPad 已经被故意去掉了——配合下面说的触屏 + 屏宽双重检测，iPad 走另一条路，否则桌面 Mac 也会被误伤。

路线三：屏幕宽度（断点）

不嗅探 UA、只看 window.innerWidth 是否小于某阈值（典型 768px 或 1024px），这种思路的本质是把"移动设备"重新定义成"屏幕窄的访问者"。它的优点是天然包容了未来出现的新设备类型，缺点是：

所以单独用屏宽不行，但屏宽 + UA 一起做反向校验很有用：UA 说是移动但屏宽超过 1366px，多半是 DeX 这种桌面模式，应该尊重用户当前的"桌面化"选择，不要强制跳 m。

路线四：Device.js 库

原文提到的 device.js（matthewhudson/device.js，最近一次发布是 2018 年）就是把上面这一堆 UA 关键词封装成 device.mobile()、device.tablet()、device.landscape() 几个 API。它的问题是维护停滞，对最近五六年的新设备已经不更新——iPadOS 桌面 UA、HarmonyOS、Edge Mobile 它都不认。

更现代的替代品是 ua-parser-js，社区活跃且支持 Client Hints 输入，做检测能拿到 device.type / device.model / browser.name 一整套。但保哥实测，单纯做"PC 还是手机"二分判断时，它依然是杀鸡用牛刀，引入近 20KB 的库只为一行 if 不划算。

路线五：UA Client Hints（推荐）

Chrome 89+、Edge 89+、Opera 75+ 已经把 navigator.userAgentData 暴露出来。核心调用：

if (navigator.userAgentData && navigator.userAgentData.mobile === true) {
  location.replace('https://m.zhangwenbao.com' + location.pathname);
}

这是 W3C 在去 UA 嗅探化路线图上给出的"祝福"接口，userAgentData.mobile 是浏览器自己声明的"我是不是移动设备"，比所有正则都准。但 Safari 至今没有实现 Client Hints（截至 2026 年 5 月仍只在 Safari 18 Technology Preview 里部分启用），所以仍然要 fallback 回 UA 正则。保哥的生产代码长这样，先看 Client Hints，没有再回退正则：

function isMobile() {
  if (navigator.userAgentData) {
    return !!navigator.userAgentData.mobile;
  }
  var ua = navigator.userAgent;
  if (/Android|webOS|iPhone|iPod|BlackBerry|IEMobile|Opera Mini|HarmonyOS|EdgA|EdgiOS|UCBrowser|MQQBrowser|Quark/i.test(ua)) {
    return true;
  }
  // iPadOS 桌面 UA 兜底：触屏 + 屏宽 < 1366
  if ('ontouchend' in document && window.innerWidth < 1366 && /Mac/i.test(ua)) {
    return true;
  }
  return false;
}

实战版重定向脚本：保留路径、防循环、记忆用户选择

原文给的脚本最大的问题是把 location 直接置成裸域名，window.location = 'http://m.zhangwenbao.com';——这意味着访客本来要看的 /notepad-edit-saved-code-...页面，跳过去之后变成了 m 站首页。Googlebot Smartphone 看到这个跳转，会判定"PC 页面在移动端实际上跳走了，且并没有跳到对应的 m 页面"，对应的 m 文章可能根本进不了移动索引。

正确的做法是：保留 path、保留 query、保留 hash，把整个 URL 部分原样接到 m 域之后。再叠加一层"用户主动选择留在 PC 版"的 cookie 记忆，否则用户每次访问都被强制跳走、永远回不到 PC 站，体验会被骂。

(function () {
  // 1. 用户已经主动选择留在桌面版，72 小时内尊重它
  if (document.cookie.indexOf('site_pref=desktop') !== -1) {
    return;
  }


  // 2. 检测移动设备
  function isMobile() {
    if (navigator.userAgentData) return !!navigator.userAgentData.mobile;
    var ua = navigator.userAgent;
    if (/Android|webOS|iPhone|iPod|BlackBerry|IEMobile|Opera Mini|HarmonyOS|EdgA|EdgiOS|UCBrowser|MQQBrowser|Quark/i.test(ua)) {
      return true;
    }
    if ('ontouchend' in document && window.innerWidth < 1366 && /Mac/i.test(ua)) {
      return true;
    }
    return false;
  }
  if (!isMobile()) return;


  // 3. 已经在 m 域上，避免循环
  if (location.hostname.indexOf('m.') === 0) return;


  // 4. 不要把搜索引擎爬虫送到 m 站，让它跟 canonical 走
  if (/bot|crawler|spider|googlebot|bingbot|baiduspider|yandexbot|sogou/i.test(navigator.userAgent)) {
    return;
  }


  // 5. 拼装目标 URL：path + search + hash 全部保留
  var target = 'https://m.zhangwenbao.com'
    + location.pathname
    + location.search
    + location.hash;


  // 6. 用 replace 而非 assign，避免在浏览历史里留一格"跳走的 PC 页"
  location.replace(target);
})();

对应在 PC 站某处放一个"切换到桌面版"的链接（典型在 m 页面的 footer），点了之后种 cookie：

document.cookie = 'site_pref=desktop; path=/; domain=.zhangwenbao.com; max-age=259200; SameSite=Lax';
location.href = 'https://zhangwenbao.com' + location.pathname;

关键的几个地方：

iPad 假桌面问题的完整解法

iPadOS 13+ 的 Safari 默认请求桌面版网站，UA 里已经没有 iPad 字样。市面上 80% 的旧检测脚本到这一步全部失效。保哥实测了三种解法：

解法一：触屏检测 + Mac UA。

var isIPad = /Macintosh/.test(navigator.userAgent) && 'ontouchend' in document;

这是 Apple 官方文档建议的写法，可靠性最高。原理是：真 Mac 不带触屏（除了几台带 Touch Bar 的，但那不是 ontouchend），所以"UA 是 Mac 但有触屏"基本就是 iPad。

解法二：屏幕分辨率特征。iPad 系列的设备像素比、screen.width 组合是稳定的——iPad mini 768x1024、iPad Air 820x1180、iPad Pro 11/12.9 1024x1366 / 1366x1024。但屏宽特征会被用户改窗口大小破坏，这条只能做"嫌疑人筛选"，不能下结论。

解法三：Maximum-touch-points。navigator.maxTouchPoints > 1 也能区分桌面 Mac 和 iPad，比 ontouchend 更现代。但 Safari 14 之前不支持，要做版本检测。

三个组合起来，保哥稳妥的写法：

function isIOSDevice() {
  var ua = navigator.userAgent;
  // 老 iPhone / iPad（UA 里有 iPhone/iPad）
  if (/iPad|iPhone|iPod/.test(ua)) return true;
  // 新 iPadOS（UA 假装 Mac）
  if (/Macintosh/.test(ua) && ('ontouchend' in document || navigator.maxTouchPoints > 1)) return true;
  return false;
}

客户端 JS 跳转 vs 服务端 UA 路由：性能与 SEO 的权衡

原文给的方案全是客户端 JS 跳转。这种方式的代价是：

  1. 用户先看到 PC 页面闪一下，HTML+CSS 已经下载、JS 解析到这段判断之后才发起跳转，相当于浪费一次完整请求加 3-5KB 关键资源。
  2. 跳转期间会请求两次主页面，CDN 命中率被压低。
  3. 慢网络下感知很差。3G 下 PC 页面可能要 2-3 秒才能开始跳，用户已经盯着白屏发呆。

更好的方案是在服务端做 UA 路由。Nginx 一段 map 就能解决：

map $http_user_agent $is_mobile_ua {
  default 0;
  ~*(Android|webOS|iPhone|iPod|BlackBerry|IEMobile|Opera Mini|HarmonyOS|EdgA|EdgiOS|UCBrowser|MQQBrowser|Quark) 1;
}


server {
  listen 80;
  server_name zhangwenbao.com;


  location / {
    # 用户偏好桌面版的 cookie 优先
    if ($cookie_site_pref = 'desktop') {
      proxy_pass http://php-upstream;
      break;
    }
    # 移动 UA 跳到 m 域
    if ($is_mobile_ua = 1) {
      return 302 https://m.zhangwenbao.com$request_uri;
    }
    proxy_pass http://php-upstream;
  }


  # 提示中间 CDN 按 UA 拆缓存
  add_header Vary "User-Agent, Cookie";
}

关键差异：

保哥实际项目里采用的是混合方案：服务端做 UA 路由作为 99% 场景的快路径，客户端 JS 作为兜底——服务端漏判（比如 iPadOS 假桌面）的情况下，PC 站点上仍然加载那段 JS 检测，触屏 + Mac UA 命中后再跳。

SEO 层面必须做对的三件事

判断脚本和重定向都不是 SEO 工作的全部，"双站架构 + 自动跳转"还有三道必答题：

canonical / alternate 配对

每一篇 PC 页面 head 里：

<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.zhangwenbao.com/this-article.html">

对应 m 页面 head 里：

<link rel="canonical" href="https://zhangwenbao.com/this-article.html">

这一对让 Google 把两个 URL 视作同一篇内容。漏配 alternate，Google 把 m 页面看成抄袭 PC 页面的近重复内容，权重稀释；漏配 canonical，移动搜索结果展示的可能是 PC URL，到了手机上点开还要再跳一次，体验+性能双扣分。

不要在 PC 上对 Googlebot Smartphone 做 UA 跳转

Googlebot Smartphone 抓 PC URL 时，UA 里既有 Mobile 又有 Googlebot。如果 UA 路由把它跳到 m 域，Google 索引里那条 PC URL 永远抓不到内容，最后它会判定 PC URL "Soft 404"。所以服务端规则要给爬虫开后门：

map $http_user_agent $is_bot {
  default 0;
  ~*(Googlebot|Bingbot|Baiduspider|YandexBot|sogou) 1;
}
# 在跳转规则前加：
if ($is_bot = 1) { proxy_pass http://php-upstream; break; }

sitemap 双份提交

Google Search Console 要把 PC 域和 m 域分别注册成两个属性，分别提交 sitemap。如果只交 PC 站 sitemap，m 站的索引覆盖率统计永远是 0；如果只交 m 站 sitemap，那 alternate 关系建立得慢。两个都交，让 Google 自动去把 alternate/canonical 对接起来。

什么时候应该放弃自动跳转

说了半天怎么做对，反过来——什么场景应当干脆不做自动跳转？保哥的三条经验：

  1. m 站和 PC 站的内容已经基本一致。如果两个站只是布局/样式不同，文字内容 90% 重叠，那双站架构的"信息架构差异"前提已经不成立，最划算的路是把 m 站做成 PC 站的响应式版本，删掉自动跳转，关停 m 子域并用 301 永久重定向到对应的 PC URL。这是 Google Mobile-First Indexing 之后绝大多数项目走的路线。
  2. m 站访问量不到主域 5%。运营成本算不过来。响应式重写一个工时，未来五年的双站维护成本也消化不了。
  3. 新做的项目。2026 年新立项的 web 应用，没有任何理由开 m. 子域。一开始就响应式，配合 viewport meta 标签和 CSS 媒体查询，比双站省 50% 维护精力。

保哥的判断很直白：客户端 JS 跳转是给"已经有了 m 站、暂时没法切走"的存量项目的过渡药，不是做新站的处方。

常见问题解答

iPad 用 Safari 访问 PC 站，UA 看起来是 Mac，这种情况能跳到 m 站吗？

能，但要靠触屏检测兜底。在 PC 站 head 里加这段 JS：先看 navigator.userAgentData.mobile（新浏览器会直接告诉你），fallback 到 UA 正则；UA 是 Macintosh 时再额外检查 ontouchend 或 navigator.maxTouchPoints > 1。这两个特征只有真触屏设备才有。一旦命中，就用 location.replace 把整段 path+query+hash 拼到 m 域上跳过去。注意 navigator.maxTouchPoints 在 iPad Pro 上稳定返回 5，桌面 Mac 返回 0，是最干净的判定信号。

为什么用户被跳到 m 站后，再点回 PC 站又被跳走，按返回键也回不来？

典型成因有两个。第一是用了 location.href 而非 location.replace，导致浏览历史里留下了"那个 0.1 秒就跳走的 PC URL"，按返回回到那一格又触发跳转，陷入循环。改用 location.replace 立刻解决。第二是切换偏好的 cookie 域写错了，应当写成 domain=.zhangwenbao.com（带前导点），这样 m 子域种的 cookie 主域才能读到。如果两个域写各自的 cookie，主域永远不知道用户已经选择了"留在桌面版"，每次访问都被踢回 m 站。还要把 SameSite 至少设为 Lax，否则跨域跳转携带不上 cookie。

UA 路由放在 Nginx 还是放在 PHP 应用层比较好？

放 Nginx 性能更好，因为请求在反向代理这一层就能 302 走，根本不用进 PHP-FPM。延迟低 30-80ms，对国内移动 4G 网络体验差异明显。但 Nginx 配置改起来要 reload，调试不如代码方便。如果项目对实时变更要求高（比如要在管理后台动态调正则），可以放 PHP 应用层（在入口 index.php 第一行做判断+header Location）。保哥常用的折中方案是 Nginx 做粗判（命中 90% 流量），PHP 兜剩下的边缘情况（iPad 假桌面、白名单 IP 等）。性能和灵活性都拿到。

响应式设计已经流行这么多年，自动跳转脚本还有必要存在吗？

对新项目没必要。新项目应当一开始就用响应式 + viewport meta + CSS 媒体查询，所有设备共用一个 URL。但对存量双站还有必要——已经积累的 m 子域外链、独立运营的轻量化资源、闭源主题无法响应式改造，这些场景下双站要继续跑，跳转脚本就得继续维护。判断标准很清楚：m 站访问量超过主域 10%、且业务上确实做了内容差异化（比如 m 站只展示核心内容）就保留双站；否则评估迁移到响应式，长期看维护成本低得多。

移动端访客被跳到 m 站后，搜索引擎能正确索引到 m 站吗？

可以，但要把 alternate/canonical 配对、Vary 头、sitemap 三件事都做对。PC 页面 head 加 link rel=alternate media="only screen and (max-width: 640px)" href 指向对应 m URL，m 页面 head 加 link rel=canonical 指向对应 PC URL，两边都要按文章一对一配。同时给 PC 域和 m 域分别在 Google Search Console 注册属性、分别提交 sitemap。再就是服务端跳转规则里要给 Googlebot/Bingbot/Baiduspider/YandexBot 开后门，不要把它们也跳到 m 站，否则 Google 抓 PC URL 拿不到内容会判 Soft 404。最后 Nginx 加 add_header Vary "User-Agent, Cookie"，让中间 CDN 按 UA 分桶缓存，避免 PC 用户拿到 m 缓存的串站事故。

device.js 这个库还能用吗，要不要换 ua-parser-js？

device.js 自 2018 年起停止维护，对 iPadOS 桌面 UA、HarmonyOS、Edge Mobile 都不识别，2026 年的生产环境不建议再引入。如果只做"PC 还是 Mobile"二分判断，写一行 UA 正则就够了，引入任何库都嫌重。如果项目有更细粒度的需求（比如要按设备型号、OS 版本做差异化处理），ua-parser-js 是目前最活跃的选择，2024 年起支持 Client Hints 输入，能识别上千种设备。代价是 gzip 后约 18KB，对首屏关键路径有影响，建议用 dynamic import 在需要时再加载。最现代的方案是直接调 navigator.userAgentData，不依赖任何第三方库。

跳转脚本应该放在 head 顶部还是 body 底部？

放 head 顶部，且写成同步代码，不要带 async/defer。放 body 底部意味着浏览器要等 HTML 全部解析完才执行跳转，用户先看到完整 PC 页面闪一下再跳，体验差。放 head 也不要 defer，否则同样会等到 DOM ready。最理想的是把这段脚本 inline 到 head 第一个 script 标签里、不超过 1KB，这样浏览器拿到 HTML 第一个 chunk 就能立即跳。同时配合服务端 UA 路由（Nginx 层 302）作为更前置的快路径，绝大多数移动访客根本进不到 PC 域，谈不上闪屏。客户端 JS 只是兜底。

判断脚本会被屏蔽广告插件或 NoScript 干扰吗？

大部分广告屏蔽插件不会拦自身脚本（你站点自己加载的代码），它们只屏蔽来自 Google Ads / 第三方追踪域名的脚本。但确实有少数极端用户开了 NoScript 全局禁 JS，他们的浏览器永远不会执行你的跳转代码，会停留在 PC 站。这部分用户量在 1% 以下，且本身就是技术高手，知道自己在干什么。要兼容他们，只能靠服务端 UA 路由——Nginx 层做 302 跳转不依赖 JS 执行。再就是 PC 页面顶部加一个明显的"前往手机版"按钮，给禁 JS 用户一个手动入口，是体验上更稳妥的兜底。

用 301 还是 302 做跳转好？

用 302。301 是永久重定向，会被浏览器和搜索引擎缓存，未来如果 m 站下线、想把流量合并回 PC 域，301 缓存清不掉，访客和爬虫都还在拿旧的跳转规则。302 是临时重定向，浏览器和爬虫每次都会重新询问，规则改了立刻生效。SEO 角度，301 会传递权重、302 不传递——但在双站自动跳转这个场景里，权重靠的是 alternate/canonical 配对，不靠 301，所以选 302 没有损失反而更灵活。如果是真正的 URL 永久变更（比如老 URL 整站迁到新域名），那场合才用 301。

如果想测试当前跳转脚本对各种设备的兼容性，有什么工具？

三层测试组合：第一层 Chrome DevTools 的 Device Mode，能模拟一两百种设备的 UA、屏宽和触屏，覆盖 80% 常见场景。第二层 BrowserStack 或 LambdaTest 这类云真机平台，能租到真实 iPad Pro、华为 Mate 60、Samsung Galaxy S 等机型跑端到端测试，价格 19 美金/月起，按小时计费。第三层用 curl -A 'UA字符串' 直接打你站点 URL，看 HTTP 状态码和 Location 响应头，验证服务端 UA 路由的命中。同时建议在 PC 域上加一个 ?nomobile=1 query 参数后门，命中时跳过整段判断，方便开发期间在手机上调试 PC 页面，不被自己的脚本踢走。

因本文不是用Markdown格式的编辑器书写的，转换的页面可能不符合AMP标准。