企业官网建设流程全解析

手机上打开正常，电脑上打开就"换了张脸"——导航挤成一条线、按钮点不动、图片糊成一片，或者干脆被跳到一个简陋的 PC 版页面。做前端的、做投放的、做测试的，甚至只是想安安静静在电脑大屏上看完一篇手机端专享长文的普通用户，都迟早会撞上"如何在电脑上浏览手机网页"这个问题。它听起来像个小白提问，实际上牵扯到用户代理识别、客户端提示、视口与设备像素比、触摸事件模拟、服务端分流逻辑这一整套东西。我把这几年在适配自查、回归测试、移动端落地页验收里反复用到的几种做法整理了一遍，从零成本的浏览器开发者工具，到可以批量出图的自动化脚本，再到真机镜像的补充手段，每一种都写清楚了操作步骤、参数怎么算、坑在哪里。不管你是刚入行的前端，还是只想过个链接看内容的普通人，都能各取所需。

1. 先把问题想清楚：为什么电脑上看手机网页这件事这么常见

1.1 谁在什么情况下需要这个能力

很多人第一次接触这个需求，是因为某个页面在手机上能打开、在电脑上点进去却是另一副样子。这类情况背后往往不是"网站坏了"，而是站点主动做了分流：它通过请求头判断你用的设备类型，然后把手机用户送到m.开头的域名或者移动端模板上。你在电脑上访问，自然就被当成桌面设备处理了。明白了这一点，后面的所有方案其实都在做同一件事——让站点"以为"你用的是手机。

具体到人群，大致可以分成三类。第一类是前端开发和测试，需要在大屏上快速验证响应式断点，改一行 CSS 立刻看效果，不用来回传包、扫码、刷新。第二类是运营和设计，要确认活动落地页在手机上的首屏高度够不够、按钮会不会被键盘挡住、弹窗有没有压住关键信息。第三类就是普通用户，可能收到一个只能在手机上打开的链接，或者想在大屏上看清楚某个移动端页面的内容。

这张表的关键信息在最后一列：还原度要求越高，你付出的操作成本就越高。所以我一般建议先用最轻的方案跑通，只有发现"模拟环境复现不了"的时候，再往上升级。这一点在后面的排查章节还会反复提到。

1.2 移动端和桌面端到底差在哪：UA、视口与渲染

想让电脑"假装"是手机，得先知道站点是用什么手段识别的。归纳下来无非两条路径：服务端识别和客户端识别。服务端识别主要看请求头里的 User-Agent 字符串，这是最传统也最普遍的一种。一个典型的移动端 UA 长这样：

Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1

和桌面版 UA 对比，它多了iPhone、Mobile这类标识，平台信息也换成了手机操作系统。服务端拿到这个字符串，做一次正则匹配，就能决定给你返回哪套模板，或者干脆 302 重定向到移动域名。除了传统 UA，近些年浏览器还增加了一套叫客户端提示（Client Hints）的请求头，比如Sec-CH-UA-Mobile: ?1就表示移动设备，Sec-CH-UA-Platform会带上系统名称。这套头是浏览器主动发送的，不能只靠改 UA 字符串来伪造。

客户端识别则发生在页面加载之后，主要是靠 CSS 媒体查询和 JavaScript。媒体查询看的是视口宽度，比如@media (max-width: 768px)；JavaScript 这边常用的判断条件包括window.innerWidth、window.matchMedia('(pointer: coarse)')、navigator.maxTouchPoints等等。这就解释了一个很多人踩过的坑：只把浏览器窗口拖窄，页面确实会变成移动端布局，但如果站点是服务端按 UA 分流的，你拿到的依然是桌面版 HTML，改窗口宽度根本没用。

再往下还有渲染层面的差异。设备像素比（DPR）决定了一个 CSS 像素对应多少个物理像素，iPhone 常见是 3，安卓主流在 2 到 3 之间，电脑显示器通常是 1 或 2。同一段代码在不同 DPR 下的粗细、模糊程度完全不一样。触摸事件也是同理，手机上是touchstart、touchmove，电脑上是鼠标事件，如果页面逻辑只监听触摸事件，电脑上就会"点了没反应"。

注意：视口宽度、用户代理、触摸能力这三样是独立的三把锁，很多站点会同时上锁。只解开其中一把，可能还是进不去移动端页面。

2. 方案选型：四种主流路线的取舍

2.1 浏览器开发者工具模拟（首选，零成本）

Chrome、Edge、Firefox、Safari 现在都内置了设备模拟功能，这是我最推荐的第一步。它的核心优势是零安装、零配置，而且能同时覆盖 UA、视口、DPR 和触摸事件这四样东西，基本把前面说的三把锁一次性解开。同时你还能在同一个窗口里看 DOM 结构、改样式、断点调试，调试效率比真机高出一大截。

它也不是没有短板。设备模拟跑的还是桌面浏览器内核，iOS 上 Safari 的一些特有行为模拟不了，GPU 渲染路径、系统字体、输入法弹出方式也都和真机有差距。所以我的习惯是：开发和初步自查全用设备模拟，交付前挑两三个关键机型用真机过一遍。这样既保证了效率，又不至于把明显的问题漏到线上。

2.2 UA 切换扩展与命令行参数（适合长期固定）

如果你需要长期以某个固定 UA 访问站点——比如做多账号的移动端页面巡检，或者某个页面在设备模拟下总是被跳转——可以考虑 UA 切换类扩展，或者用启动参数直接指定。以 Chromium 内核浏览器为例：

chrome --user-agent="Mozilla/5.0 (Linux; Android 13; Pixel 7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36"

这种方式的优点是全局生效、启动即用，不需要每次开面板调设置。缺点是它只改 UA，视口宽度、DPR、触摸事件都还是桌面的，遇到响应式设计的站点，布局依然是 PC 版。而且扩展类的工具质量参差不齐，有些会夹带额外的请求，装之前最好看一眼权限列表。

2.3 真机镜像与安卓模拟器（适合验证真实交互）

再往上一步，就是直接把手机屏幕搬到电脑上。安卓这边可以用投屏类工具，把手机画面实时镜像到桌面窗口，然后用鼠标键盘反向操作手机。也可以装一个安卓模拟器，在电脑上跑一个完整的安卓系统。这两种方式的还原度最高，因为渲染和交互确实发生在真实的移动系统里。

代价也很明显：启动慢、占资源，多开几个实例机器就开始发烫。而且模拟器毕竟是虚拟环境，部分依赖硬件的能力——摄像头、指纹、部分传感器——要么不支持，要么需要额外配置。我一般只在需要验证"真机才能复现的诡异问题"时才动用它，日常调试不会碰。

2.4 自动化脚本批量截图（适合回归测试）

如果你需要定期检查几十个页面的移动端表现，或者做发版前后的视觉对比，手动开面板显然不现实，这时候就该上自动化了。Playwright 和 Puppeteer 都内置了设备描述符，一行代码就能模拟某款机型的完整环境，还能顺手截图、抓取关键元素的尺寸。这套方案适合集成到发版流程里，但我得提醒一句：这类工具默认不开界面，出问题时排查比手动慢，建议先在手动环境里把问题定位清楚，再用脚本固化下来。

3. 手把手实操：Chrome 与 Edge 的设备模拟完整流程

3.1 打开设备工具栏与常用快捷键

先说入口，因为它藏得有点深。最直接的方式是打开开发者工具后按Ctrl + Shift + M，Windows 和 Linux 都是这个组合，Mac 上是Cmd + Shift + M。另一个入口在面板左上角，是一个"手机加平板"的小图标，点一下就能切换。如果找不到，可以在开发者工具右上角的三个点菜单里找"更多工具"，里面有一项"设备工具栏"。

打开之后，页面左侧区域会变成一个设备视口，顶部多出来一条工具栏。这条工具栏从上到下依次是设备下拉框、尺寸输入框、DPR 下拉框，以及旋转、缩放、截图这些按钮。很多人第一次打开会觉得页面变得很奇怪，其实是正常的——你现在的视口宽度被改成了某个手机的宽度，页面自然按照移动端布局重新排版。

提示：如果你想让设备模拟的设置在关闭开发者工具后依然保留，可以在设备工具栏右上角的菜单里勾选相关选项。不过大多数情况下保留设置反而容易造成困惑，我习惯让它每次重置。

3.2 设备选择、自定义尺寸与 DPR 设置

设备下拉框里预置了一大批常见机型，从早期的 iPhone 到最新的几代都有，安卓阵营主要是 Pixel 和 Galaxy 系列。选一个机型之后，宽度、高度、DPR、UA 会一起被设置好，这也是我推荐用预置设备而不是手动填的原因。

如果预置列表里没有你要的机型，可以点"编辑"进入自定义设备页面，新增一条。这里需要填四项：设备名称、UA 字符串、视口宽高、以及 DPR。宽高怎么确定？最简单的办法是查一下该机型的官方分辨率，再除以 DPR。举个例子，某款机型标称分辨率是 1179 × 2556，DPR 为 3，那么 CSS 视口就是 393 × 852。这个换算关系一定要搞清楚，因为它直接决定了你的断点会不会命中。

CSS 视口宽度 = 物理分辨率宽度 / 设备像素比 1179 / 3 = 393 2556 / 3 = 852

安卓这边常见的组合是 1080 × 2400 配 DPR 3，换算下来视口是 360 × 800。这也是为什么很多设计稿按 375 宽度出图，而实际开发时要在 360 到 414 之间留出弹性——不同机型的 CSS 视口宽度本来就不一样。我自己习惯至少准备三条自定义设备：一条小屏 360、一条主流 393、一条大屏 430，覆盖绝大多数断点场景。

3.3 修改 UA 与客户端提示的正确姿势

前面说过，识别手段有传统 UA 和客户端提示两套。设备模拟里的"设备"下拉框会同时处理这两者，所以用预置设备最省心。但如果你需要临时改成一个自定义的 UA，就会用到"网络条件"面板里的用户代理输入框。

这里有个细节值得说清楚：手动填写 UA 字符串时，客户端提示请求头不一定跟着变，因为那套头是浏览器根据自身情况生成的，不完全是 UA 的派生结果。实测中我就遇到过这样的情况——UA 改成安卓机型了，页面上还是桌面版，抓请求头一看，Sec-CH-UA-Mobile依旧是无值状态。解决办法有两个：一是尽量用设备模式或自定义设备，二是如果非要手填 UA，就同时在页面里用 JavaScript 覆写相关判断。

另一种常见做法是在页面控制台里直接覆写，比如：

Object.defineProperty(navigator, 'maxTouchPoints', { get: () => 5 }); window.matchMedia = (query) => ({ matches: query.includes('pointer: coarse') || query.includes('max-width'), media: query, addListener() {}, removeListener() {}, addEventListener() {}, removeEventListener() {}, });

这种写法属于"暴力篡改"，只适合临时在控制台里验证某个判断条件，不要写进正式代码里。它的价值在于帮你快速确认：站点到底是靠哪一条规则做的分流。确认完之后，正确的做法还是回到设备模式，那才是干净的模拟环境。

3.4 触摸事件、网络限速与位置模拟

设备工具栏里还有一个容易被忽略的开关，就是触摸模拟。开启之后，鼠标按住拖动会被浏览器翻译成触摸事件，touchstart和touchmove就能正常触发。如果你在调试滑动轮播、下拉刷新、手势返回这类组件，这个开关必须打开，否则你会在控制台里看到一片空白，误以为代码写错了。

网络限速在"网络"面板里设置，可以选预设的慢速网络档位，也可以手动指定下行速率和延迟。做移动端页面时我一般会打开这个功能跑一遍首屏，因为很多问题只在慢速网络下才暴露出来：骨架屏闪烁、图片加载顺序错乱、首屏字体跳动。位置模拟则在"传感器"面板里，可以覆盖经纬度，用来测试依赖地理位置的页面逻辑。

这三样东西加起来，基本能覆盖移动端的大部分调试场景。但请记住，模拟终究是模拟。触摸事件的时序、限速的真实抖动、定位的精度误差，和真机都有差距。

3.5 移动端专属页面（m. 域名）与登录态的处理

移动端页面还有一个让人头疼的地方：登录状态。很多站点的移动端和桌面端用的是不同的会话标识，你在电脑上登录了桌面版，切到移动版 UA 打开m.域名，依然是未登录状态。这时候不要怀疑是模拟失效了，它只是把"浏览器身份"换掉了，Cookie 该有的还是没有。

处理方式有两种。一种是在模拟状态下重新登录一次移动端，之后在这个开发者工具窗口里保持会话。另一种是直接在地址栏手动输入移动端域名，同时在设备模拟状态下访问，避免被重定向回桌面站。需要注意的是，不同域名的 Cookie 是互相隔离的，桌面站的登录态不会自动带过去。

注意：频繁切换 UA 反复登录同一个站点，部分站点会触发风控提示，比如要求二次验证或者临时限制访问。做这类操作时把节奏放慢一点，不要写个循环脚本去刷。

4. Firefox、Safari 与国产浏览器的差异操作

4.1 Firefox 的响应式设计模式

Firefox 里对应的功能叫"响应式设计模式"，快捷键同样是Ctrl + Shift + M。它的界面和 Chrome 略有不同，顶部是一条可以拖动的宽度手柄，你可以直接拖着改变视口宽度，观察布局在各个宽度下的反应，做断点调试特别直观。右侧的工具栏里可以添加自定义设备，设置宽高、DPR 和 UA。

它有个我很喜欢的小功能：视口旁边会实时显示当前尺寸，拖动的时候数字跟着变，你不用去猜宽度到了多少。另外它的触摸模拟开关比较明确，就在工具栏上，开启后鼠标操作会被翻译成触摸事件。缺点是对客户端提示的支持不如 Chromium 系完整，遇到靠这套头分流的站点，还是得换浏览器。

4.2 Mac 上 Safari 的响应式设计模式

如果你要验证 iOS 上的表现，Safari 的设备模拟是绕不开的，因为它和 iOS 上的 Safari 用的是同一套渲染引擎。默认情况下 Safari 的开发菜单是隐藏的，需要先去偏好设置里，找到"高级"标签，把"在菜单栏中显示开发菜单"勾上。

之后在开发菜单里就能找到"响应式设计模式"和"进入响应式设计模式"。它的设备列表里可以直接选各种 iPhone 和 iPad，UA、视口、DPR、触摸能力都会一起切换。我个人的经验是：只要项目需要兼容 iOS，最终验收一定要在 Safari 的设备模式里过一遍，尤其是100vh相关的布局、固定定位的底部栏、以及滚动回弹引起的视觉差异，这些在 Chromium 里往往看不出来。

4.3 国产浏览器与内核差异

国内常见的几款浏览器大多基于 Chromium 内核，开发者工具的整体结构和 Chrome 基本一致，入口可能放在"工具"或者"更多工具"下面，快捷键也可能被占用或改成别的组合。功能上差别不大，设备列表可能更新得慢一些，预置机型偏旧。

真正需要注意的是"双核"浏览器。这类浏览器会在不同场景下切换内核，你在某一个内核里做的模拟设置，换到另一个内核里完全无效。如果发现设备模拟怎么调都不生效，先确认当前用的是哪个内核，必要时切到 Chromium 内核再试。另外，部分浏览器会自带"极速模式/兼容模式"的切换按钮，它本质上就是换内核，也会影响模拟结果。

5. 自动化与批量方案：用 Playwright、Puppeteer 复现手机环境

5.1 Playwright 的设备描述符用法

Playwright 内置了几十种设备的描述符，包含 UA、视口、DPR、触摸支持、是否移动端等完整信息，用起来非常省事。Python 版本大概是这样：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch() context = browser.new_context(**p.devices["iPhone 13"]) page = context.new_page() page.goto("https://www.example.com", wait_until="networkidle") page.screenshot(path="iphone13.png", full_page=True) context.close() browser.close()

关键就在new_context(**p.devices["iPhone 13"])这一行，它把整套设备参数一次性注入进去，比手动逐个设置可靠得多。如果你需要同时跑多款机型，可以把设备名放进一个列表里循环，每个机型单独开一个 context，互不干扰。

5.2 Puppeteer 手动覆盖 UA 与视口

Node 环境下用 Puppeteer 的话，参数需要手写，但胜在可控性更强：

const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch({ headless: 'new' }); const page = await browser.newPage(); await page.setUserAgent( 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 ' + '(KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1' ); await page.setViewport({ width: 393, height: 852, deviceScaleFactor: 3, isMobile: true, hasTouch: true, }); await page.goto('https://www.example.com', { waitUntil: 'networkidle2' }); await page.screenshot({ path: 'mobile.png', fullPage: true }); await browser.close(); })();

这里的isMobile和hasTouch两个字段很关键。前者会影响浏览器对视口元标签的处理方式，后者决定触摸事件会不会被派发。只设宽度不设这两个，很多页面依然会按桌面逻辑渲染。

5.3 批量截图与前后对比的工作流

如果你要做发版前后的视觉回归，单张截图意义不大，有价值的是对比。我的做法是：每次跑完把截图按"机型-页面-时间戳"命名存到一个目录里，然后用图像对比工具做逐像素比较，只输出有差异的区域和差异比例。差异超过阈值的页面单独列出来人工看，其余的直接放过。

在正式批量跑之前，先确认一个前提：目标站点是否按 UA 做服务端分流。用下面这条命令可以快速验证，看返回状态码和响应头里有没有重定向：

curl -s -I -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" https://www.example.com

如果返回 301 或 302，并且Location指向m.开头的域名，那说明服务端确实在按 UA 分流，你的脚本必须带上正确的 UA，否则截出来的全是桌面版。这个检查花不了三十秒，却能省掉后面一堆莫名其妙的排查。

提示：批量脚本跑之前，先给目标站点确认一下访问频率的合理性。逐页串行、每页之间留出间隔，对站点和自己的网络都好。

6. 常见问题与排查实录

6.1 模拟了还是跳到 PC 版：五步排查法

这是被问得最多的一类问题。明明开了设备模式，页面还是跳回桌面站，或者布局纹丝不动。我的排查顺序基本固定，按下面五步走，绝大多数情况都能定位。

第一步，看首次请求。打开网络面板，勾上"保留日志"，然后刷新页面。看第一条文档请求的响应状态，如果是 3xx，看Location指向哪里。如果它跳到桌面域名，说明是服务端按 UA 分流，你的 UA 没设置对。

第二步，确认 UA 是否真的生效。在网络面板里点开任意一条请求，看请求头里的User-Agent字段，别只看设备下拉框显示的名字。有时候下拉框显示的是 iPhone，实际请求头里的 UA 还是桌面版，这种情况通常是因为在"网络条件"面板里手动填写了 UA，覆盖了设备设置。

第三步，检查客户端提示头。搜一下请求头里有没有Sec-CH-UA-Mobile，它是不是?1。如果没有或者值不对，而站点又依赖它，那就要回到设备模式重新设置。

第四步，检查是否有 JavaScript 层面的判断。可以在页面加载前打断点，或者在控制台里查看innerWidth、maxTouchPoints这些值是否符合预期。有些站点会在页面加载后立刻执行一次设备检测，不满足条件就location.replace到桌面版。

第五步，检查缓存。这一点最容易被忽略。如果站点注册了 Service Worker，即使你改了 UA，页面可能还是从本地缓存里读出来的旧内容。这时候要么在应用面板里注销 Service Worker，要么在网络面板里勾选"停用缓存"，再刷新一次。

6.2 布局错位、字体大小与 1px 边框问题

设备模拟下经常会看到一些"看起来很怪"的现象，但它们未必是 bug，很多时候只是移动端本来就长这样，只是你在电脑上不习惯。最典型的是 1px 边框。在 DPR 为 1 的显示器上，1px 就是实实在在的一个物理像素；到了 DPR 为 3 的手机上，1px 会被渲染成三个物理像素宽，看起来就偏粗。所以很多团队会用缩放或者极细线方案处理，你在模拟环境里看到的"细得几乎看不见"的边框，恰恰是它的正常形态。

字体也是一个高频疑问。移动端系统默认字体和桌面不一样，字重、行高、字间距都有差异，同一段文字在两边看起来的疏密程度不同。再加上一部分页面会根据 DPR 选择不同分辨率的图片，模拟环境下拉到的可能是高清图，视觉上反而比真机更锐利。我的建议是：不要用"看起来像不像"来判断对错，而是用开发者工具量元素的实际尺寸和计算样式，拿数据说话。

还有一个坑是视口单位。100vh在移动端浏览器里，会因为地址栏的收起展开而反复变化，导致固定高度的容器跳动。这个问题在桌面模拟下几乎必然复现，但复现的方式和真机不一定相同。稳妥的做法是用100dvh这类动态视口单位，或者直接用 JavaScript 取实际高度。

6.3 触摸、滚动、弹窗与输入相关的坑

触摸相关的排查其实很简单：先确认触摸模拟开了没有。如果开了还是没反应，就在事件监听面板里看一下对应元素上到底挂了哪些监听器，是touchstart还是click，有没有passive标记导致阻止默认行为失效。有些组件库会同时监听两类事件并按环境选择，模拟环境下的判断条件和真机不同，就会出现"电脑上能点、手机上不能点"或者反过来的情况。

滚动方面，移动端页面的惯性滚动、滚动穿透、滚动到底部触发加载，在桌面环境里的表现都不太一样。尤其是弹窗打开后禁止背景滚动这类实现，桌面用overflow: hidden就能搞定，移动端还得处理触摸穿透。模拟环境下测这类问题，建议同时开着触摸模拟，用拖动的方式去验证，而不是用滚轮。

输入相关的坑更隐蔽。移动端键盘弹出会改变可视区域高度，很多底部固定按钮会被顶起来或者被遮住。桌面模拟下没有虚拟键盘，这个问题压根不会出现，只能靠真机或者手动模拟视口高度变化来验证。

6.4 缓存与 Service Worker 导致的"改了没变化"

这个坑我在项目里见过太多次。改完代码，刷新页面，设备模拟下依旧是旧样子，切到真机也一样，最后发现是 Service Worker 把旧资源缓存住了。它的特点是优先级很高，甚至在网络请求之前就拦截了。排查顺序是：打开应用面板，看有没有已注册的 Service Worker，有就先注销；然后在网络面板勾上停用缓存；最后用强刷。

另外还有一种情况是 CDN 缓存。你改的是源站，但浏览器拿到的是边缘节点上的旧文件。这种情况下可以在请求 URL 后面加一个随机查询参数，绕过缓存。做回归测试的时候，我更倾向于每次都用一个全新的浏览器上下文，避免任何历史状态干扰。

6.5 常见问题速查表

7. 一些实战心得与边界提醒

7.1 模拟环境的能力边界

用了几年下来，我的判断是：设备模拟能覆盖八成以上的日常调试需求，但那剩下的两成往往是线上事故的高发区。它模拟不了的东西包括：真实的 GPU 渲染路径、系统字体渲染差异、iOS 上的滚动回弹、输入法的候选框行为、以及依赖硬件的能力。还有一类很特殊的情况是微信、支付宝这类应用内置的浏览器，它们的 UA 里带有应用标识，页面可能专门为它们做了适配，你在普通浏览器里怎么模拟都对不上。

另一个容易被忽略的点是性能。设备模拟跑在桌面硬件上，帧率、内存、CPU 都远好于真机。一个在模拟环境里丝滑的动画，到了中低端手机上可能就是掉帧的。所以只要项目对流畅度有要求，就必须安排真机实测。

7.2 什么时候必须上真机

我给自己的规则是三条：涉及支付、涉及相机麦克风等硬件、涉及第三方应用内打开。这三类场景一律真机验证，不做任何例外。除此之外，还需要真机过一遍的包括：首屏加载速度、长列表滚动的流畅度、键盘弹出后的布局、以及横竖屏切换。

真机验证也不需要很多台设备。我的经验是准备三台就够：一台小屏安卓、一台主流尺寸安卓、一台主流 iPhone。小屏负责暴露拥挤问题，主流尺寸负责确认常规体验，iPhone 负责暴露 iOS 特有的渲染差异。这三台过完，剩下的机型大多是同一类问题。

7.3 操作习惯上的一些小建议

最后分享几个我养成的小习惯。第一，调试时始终开着"保留日志"和"停用缓存"，这两个开关能省掉大量"为什么没变化"的困惑。第二，给不同的调试场景准备独立的浏览器用户配置文件，避免登录态和扩展互相干扰。第三，把常用的自定义设备一次配好，包括宽高、DPR 和 UA，之后直接选就行，不用每次手填。第四，遇到只在特定机型才出现的问题，先截图记录下来，包括当时的视口尺寸和 UA，否则回过头来根本复现不了。

至于访问频率，我的做法是任何批量脚本都串行执行，页与页之间留出合理的间隔，不要并发轰炸同一个站点。这既是基本的礼貌，也能避免因为触发风控导致整批任务失败。

注意：把电脑伪装成手机去访问页面，本身只是一种调试和查看手段。用它绕过正常访问限制、批量抓取内容或者做高频请求，都可能违反站点的使用条款，这类事情不要做。

说到底，这套东西的价值不在于"骗过网站"，而在于让你在效率最高的环境里把移动端的问题看清楚。工具会换代，识别手段会升级，但底层那几把锁——用户代理、视口、触摸能力——短期内不会变。把这三样摸透，再花哨的方案你也能一眼看穿它在做什么。我个人最常用的一套组合是：日常改样式用设备模式，涉及 iOS 的差异用 Safari 的设备模式过一遍，发版前用自动化脚本批量出图做对比，最后拿三台真机做终检。这套流程跑顺了，移动端适配这块基本不会再出现让你半夜爬起来处理的意外。