你有没有遇到过这种头疼的问题！
"用户反馈页面打不开了。"
"测试环境，预发布环境都复现不了。"
"让我看看控制台报什么错……等等，用户用的是手机，看不了控制台 ？/(ㄒoㄒ)/~~"
做前端的朋友应该都经历过这种对话。PC 上出问题，F12 一开什么都有；一旦问题发生在移动端、发生在线上，你会发现手里什么工具都够不着：手机上没有 DevTools，用户大概率也不愿意配合你折腾，报错信息全靠猜。就算你连接上生产环境的手机，各种安全限制，抓包也是十分头疼的。
除了手机，包括现在的飞书，钉钉，企业微信里的应用，都没有控制台啊，出了问题怎么办？这就是「虚拟控制台」这个功能想解决的问题。
一、移动端调试到底难在哪
先把痛点说清楚，不然没法理解为什么需要这个功能。
开发环境里我们习惯用 vConsole：挂一个进去，手机上就能看日志、看请求、看缓存，跟 PC 控制台差不多。但它有个要命的问题——开关是写在代码里的，带到线上去就完蛋了。
这意味着 vConsole 要么常开、要么常关，代码上了线就改不了。生产环境是绝不可能让每个用户右下角都挂个绿色vConsole按钮，这是妥妥的生产事故。
于是大家只能退而求其次：
- 让用户录屏。用户录了 30 秒，有用的画面 3 秒，还经常录完找不到文件在哪。
- 教用户在手机浏览器里找"开发者选项"。话说到一半，用户已经说"算了我不弄了"。
- 在代码里留调试后门，URL 拼个参数就能开 vConsole。这个最危险，参数一旦传出去，谁都能开，等于给线上埋了颗雷。
说到根儿上，这些方案都缺一样东西：一个能在生产环境、针对指定用户、实时生效的控制台开关。
二、虚拟控制台：把开关挪到服务端
Webfunny 的虚拟控制台干的就是这件事：vConsole 的开关不在代码里，在后台管理界面上。想给谁开就给谁开，什么时候开、什么时候关，你说了算。
三个特点：
1. 按 userId 精确开启。只有接入了探针、传了业务 userId 的用户，才能被开启虚拟控制台。这一步既是为了定位到人，也顺便保证了可控性——不会出现路人甲也能开出控制台的情况。
2. 实时生效，任何环境都行。预发布、灰度、生产，只要是接入了 Webfunny 的环境都能开。灰度阶段给灰度用户开，生产出事故给问题用户开。
3. 说关就关。后台点一下关闭，用户下次刷新页面，vConsole 就消失了，不留痕迹。
三、操作简单，就三步
第一步，进入「远程调试」页面，找到目标用户。如果你只有手机号或者大概的访问时间，可以先到「用户细查」里按 userId、IP、访问时间、页面路径把人筛出来。
第二步，在用户列表里点击「虚拟控制台」，开启这个用户的控制台状态。
第三步，联系用户刷新页面。刷新后页面右下角会出现 vConsole 的图标，点开就是熟悉的控制台——日志、网络请求、缓存，都在里面。
到这里，是不是觉得线上问题定位也是非常方便的呢？至少你不会对线上问题感到恐惧了，因为你又多了一种定位原因的能力了。
三、配合「用户连线」，凑齐远程调试全家桶
虚拟控制台解决的是"让用户端出现控制台"，但有时候光有控制台还不够。比如你想知道用户刚刚点过什么、本地缓存里存了什么脏数据。
这时候可以配合「用户连线」一起用。连上之后，可以看到用户在页面上产生的行为会实时同步到后台；console.log / console.warn 的输出也会实时上报，你在电脑前就能看到用户手机里打印的日志；本地缓存（localStorage、sessionStorage、cookie）大约 20 秒更新一次；还能远程操作缓存：发现 cookie 里躺着个坏 token，点一下清理，直接远程清掉让用户重新登录，不用教用户在手机设置里翻半天。
最后、虽然我们能在线上开启vConsole了，但是它仅仅是多提供了一个排查的入口，未必能帮我很好的定位问题。如果要真正定位问题的根因，还是需要一个全链路的排查工具，快来试试Webfunny全链路分析系统吧。