揭秘Spy-Debugger的工作原理与实战应用技巧
轩辕仙仙先看效果，再看代码
我最近在搞一个 H5 活动页，要适配各种安卓机和 iOS，调试简直反人类。尤其是线上用户说“点不动”“滑不动”，你本地又复现不了，纯靠猜。直到我用了 Spy-Debugger，直接打开手机页面，Chrome DevTools 看得一清二楚——就跟本地调试一样爽。
这玩意儿不是什么新工具，但很多人还在用 vConsole 或者手写 log 打印，效率低到爆。Spy-Debugger 是基于 WebSocket 的远程调试代理，原理简单：你在手机上引入一段 JS，它会把 console、network、element 变化等数据实时传回你电脑上的一个 Web 页面，你用 Chrome 就能操作。
// 这是我在项目里直接加的 script 标签（仅开发环境）
(function() {
if (location.hostname === 'localhost' || location.hostname === '127.0.0.1') return; // 本地不加载
const script = document.createElement('script');
script.src = 'https://cdn.jsdelivr.net/npm/spy-debugger@latest/dist/spy.min.js';
script.onload = function() {
Spy.enable({
host: 'your-pc-ip:9876', // 注意！这里必须是你电脑的局域网 IP
project: 'h5-campaign-2024',
injectDevtools: true // 关键！自动注入 DevTools UI
});
};
document.head.appendChild(script);
})();上面这段代码我放在所有 JS 加载之前，确保最早执行。注意那个 host 字段，必须是你本机的局域网 IP，比如 192.168.1.103:9876，不能写 localhost 或 127.0.0.1，否则手机连不上。
启动服务？别照文档抄，我踩过坑
官方文档说跑 spy-server 就行，但我折腾了半天才发现几个关键点：
- 必须指定
--host和--port，默认绑定的是 127.0.0.1，手机根本访问不到 - 如果你用的是 Mac 或 Linux，记得关防火墙，或者开放 9876 端口
- Windows 用户更要小心，有些杀毒软件会拦截自建服务
所以我现在的启动命令是这样的：
spy-server --host 0.0.0.0 --port 9876 --allow-origin *--host 0.0.0.0 是重点，意思是监听所有网卡接口，这样手机才能通过局域网 IP 访问你。然后你在手机浏览器打开页面，就能看到控制台日志实时推送了。
这个场景最好用：抓 network 请求异常
上周有个问题，用户提交表单没反应，log 显示“请求失败”，但 statusText 是空的。我用手机自带浏览器打开，devtools 根本打不开。后来上了 Spy-Debugger，直接在“Network”面板看到：OPTIONS 预检请求被拦截，CORS 报错。
原来后端 API 域名没加白名单，但只在某些安卓 WebView 里出问题，iOS 和 Chrome 正常。这种问题不靠远程抓包真找不到。
你可以用下面这个配置增强 network 监听：
Spy.enable({
host: '192.168.1.103:9876',
project: 'h5-form-debug',
injectDevtools: true,
capture: {
network: true,
console: true,
elements: true,
performance: false // 不开启，影响性能
}
});实测开启 performance 会导致低端机卡顿，所以建议关掉。network 和 console 足够用了。
元素调试也能做？有点意思
你以为只能看 log 和请求？错。Spy-Debugger 支持 element 面板，可以高亮节点、查看 computed style、甚至临时改 DOM 结构。
比如我遇到一个按钮点击区域太小的问题，设计师说“明明很大”，结果我用 Spy 的 Elements 面板一看：touch-action: manipulation 没生效，实际可点击区域只有 20px 高。
这时候你可以在面板里直接给元素加上 border 测试：
.debug-tap-area {
border: 2px solid red !important;
}然后在 Spy 的控制台执行：
document.querySelector('#submit-btn').classList.add('debug-tap-area');手机上立刻看到红色边框，直观得很。改完样式还能热更新，不用重新发包。
踩坑提醒：这三点一定注意
我用了两周，总结三个必踩的坑，提前告诉你，省得像我一样熬夜排查：
- 手机和电脑必须在同一局域网。别说你手机开热点连电脑 WiFi，也不行。必须是同一个路由器下发的 IP，不然 WebSocket 握手失败。
- 不要在生产环境留 Spy 代码。我有一次忘了删，上线后发现所有用户都在连我们的调试服务器……虽然没数据泄露，但日志炸了。建议用构建变量控制：
// webpack define plugin 注入
if (process.env.DEBUG_MODE) {
// 动态加载 Spy
}- Spy 会轻微拖慢页面。尤其是低端安卓机，开启 elements 监听后，滚动可能掉帧。建议只在调试时开启，日常开发还是用 Chrome inspect + USB 调试。
高级玩法：自定义消息通道
除了内置功能，Spy 还支持自定义事件通信。比如我想监控路由变化：
// 在 SPA 路由钩子中
function logRoute(to, from) {
if (window.Spy && Spy.emit) {
Spy.emit('custom:route-change', { to, from, timestamp: Date.now() });
}
}
// 然后在 DevTools 控制台监听
Spy.on('custom:route-change', function(data) {
console.log('[Route] ', data.to, ' <= ', data.from);
});这样你就能在调试面板里看到完整的路由跳转轨迹，比翻 console.log 快多了。
类似的，还可以用来传埋点事件、手势状态、权限开关等运行时上下文信息。
别指望完美，但它够用
说实话，Spy-Debugger 不是银弹。它有局限：
- 不支持 Storage 面板（你没法看 localStorage）
- Performance 面板基本鸡肋，数据不准
- 某些加密 WebView（比如微信 X5 内核）会阻止 WebSocket 连接
但我们本来也不是为了替代 Chrome inspect。它的核心价值是：快速定位线上问题。当用户说“不行”，而你本地没问题时，这才是真正的生产力工具。
我现在标准流程是：发现问题 → 开启 Spy → 用户复现 → 抓日志/网络 → 定位 → 修复 → 关闭 Spy。整套流程十分钟搞定，以前至少半小时起步。
结尾碎碎念
以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多，比如结合 sourcemap 查看压缩后的代码、用自定义插件扩展面板功能，后续会继续分享这类博客。
以上是我个人对 Spy-Debugger 的完整讲解，有更优的实现方式欢迎评论区交流。毕竟前端这行，谁还不是边踩坑边活着呢。
暂无评论