VConsole动态加载最佳实践：按需引入、安全可控的调试方案

1. 不是矫情：调试面板为什么要做成“偷渡”的

先讲个真实翻车现场。早几年我接了个移动端H5报价页面，就一个活动页，上线后用户反馈页面卡顿，网络面板里看到加载了十几个JS文件，其中就有个500KB的vconsole.min.js。问题是那个页面是我从同事手里接过来的，他是图省事，直接在入口HTML里写死了<script src="vconsole.min.js">，同时在另一个公共JS里new VConsole()。结果这个原本只给开发自测用的工具，就这么跟着线上流量跑了两个多月——直到某个用户把悬浮球点开，把console里的接口报文截了图发到客服群，我们才发现不对劲。

这事儿让我彻底改了习惯：VConsole必须按需加载，而且要在该出现的时候才出现。这里说的“动态加载”不是随便写个if (isDev) import('vconsole')就完事儿，而是要把加载时机、加载方式、销毁策略、安全边界全部考虑清楚。

可能有人问：VConsole有没有那么罪大恶极？你真上线带着它，它又能怎样？首先，几百KB的JS意味着用户要白等几百毫秒，尤其在弱网环境，这笔账划不来；其次，悬浮球的存在会遮挡页面操作，误触率明显上升；最重要的是，console信息里经常带着token、用户手机号、内部接口路径，这些东西暴露给任何会按F12的人，都是一种安全隐患。所以这个事不是“洁癖”，是工程化思考里绕不开的一环。

那为什么不直接在源码里写if(process.env.NODE_ENV!=='production')？因为这个判断只能做到“生产环境不带”，但实际工作中我们经常遇到：测试同学在线上环境想调试、产品拿真机在演示现场想抓包，或者线上突然出问题需要临时看console——这时候如果完全砍掉VConsole，你什么都看不了。真正灵活的做法，是把它做成一个可以随时唤醒的门：它可以不存在，但你需要它的时候，一个地址参数、一个手势、一个配置项，它就能立刻出现。这就是动态加载最大的价值。

这一篇我会把实操层面的完整方案写清楚：动态加载的几种姿势、加载时机的设计、以及我这几年代码生涯里踩过的各种VConsole动态加载的坑。不废话，直接进正题。

2. 三种动态加载VConsole的落地姿势与选型

动态加载不是说“等到要用的时候再下载”，它指的是把VConsole的JS拆分成一个独立chunk（或远程脚本），在满足特定条件时再注入到页面中。根据项目的技术栈和部署方式，目前最常见的做法有三种。

2.1 姿势一：script标签临时注入，最粗暴也最可控

第一种是传统方式：在需要出现VConsole的时机，往document.head里动态塞一个<script>标签，等它加载完再new VConsole()。

function loadVConsole() { return new Promise((resolve, reject) => { // 防止重复注入 if (window.VConsole || document.querySelector('#vconsole-script')) { resolve(window.VConsole); return; } const script = document.createElement('script'); script.id = 'vconsole-script'; script.src = 'https://cdn.example.com/vconsole.min.js'; script.onload = () => { resolve(window.VConsole); }; script.onerror = (e) => { reject(e); }; document.head.appendChild(script); }); } // 使用时 loadVConsole().then((VConsole) => { const vConsole = new VConsole(); window.vConsole = vConsole; });

为什么说它“最可控”？因为这种方式完全绕开了打包工具。哪怕你的项目是用jQuery加一堆原生JS拼出来的老古董，哪怕连npm都用不了，只要能写原生JS，就能用这套方案。它的src可以指向CDN，也可以指向项目静态目录里的相对路径，两者区别后面我会专门讲。

这个方案的缺点是容易“失控”的恰恰也是它自己。第一个坑是缓存问题：CDN的vConsole文件可能过期，尤其你用的还是某个老版本时，CDN边缘节点给你缓存了一个旧版本，你在上面做的自定义配置全部失效。第二个坑是CSP（内容安全策略）——现代网站一般都会加script-src白名单，你直接在运行时创建script标签，如果CDN域名不在白名单里，这一步直接失败。第三个坑是加载时序：如果页面在DOMContentLoaded之后才触发，你请求的接口可能已经返回好几轮了，VConsole面板里看不到最开始的几条日志，这个光靠后端打点补不回来。

所以这种姿势适合的项目：没有构建工具、部署静态文件、快速上线的轻量活动页。你可以把loadVConsole函数放在公共JS里，顺便在页面上监听地址栏参数，实现“特定链接自动开启调试”。

2.2 姿势二：ES Module的import()按需加载，工程化项目首选

如果你用的是Vite、Webpack这些带es module能力的构建工具，那么import()是更优雅的选择。它的好处是代码分割是构建工具帮你做的，开发时你正常写import VConsole from 'vconsole'，打包后它会被单独切成一个chunk，平时不会出现在主bundle里。

export async function loadVConsole() { // 防止窗口上已有实例 if (window.vConsole) return window.vConsole; const { default: VConsole } = await import('vconsole'); const vConsole = new VConsole(); window.vConsole = vConsole; return vConsole; }

这只是最基础的形式。针对工程化项目，我会在函数里加更多的“防御逻辑”，让它更贴合业务。比如：

let loadPromise = null; export function loadVConsole() { if (window.vConsole) return Promise.resolve(window.vConsole); if (loadPromise) return loadPromise; loadPromise = import(/* webpackChunkName: "vconsole" */ 'vconsole') .then(({ default: VConsole }) => { const vConsole = new VConsole(); window.vConsole = vConsole; return vConsole; }) .catch((err) => { console.warn('[vconsole] load failed', err); loadPromise = null; // 失败后允许重试 throw err; }); return loadPromise; }

注意这里用了loadPromise缓存。如果你在页面里多个地方同时调用loadVConsole()，比如路由守卫、某个按钮事件、还有业务接口的拦截器同时触发，那每个调用都会走到import()，虽然动态import本身有缓存，但后面两个调用拿到的promise其实是同一个，不会重复执行new VConsole()。不过new VConsole()这行不能瞎写，我们得用window.vConsole或模块级变量判断。

这种姿势的最大优势是配合构建工具的tree-shaking和缓存策略，打包后的vconsole chunk文件名会带上hash，CDN更新天然无痛点。另外import()本身是异步的，你可以在Promise回调里做后续处理，比如给它配置插件、设置版本号等，非常灵活。对于Vue和React项目，是绝对的首选。

2.3 姿势三：基于构建工具的glob批量导入，适合多页面复杂应用

有些场景不是一个VConsole这么简单。比如你维护的是一个多页面应用，或者微前端架构，里面有几个子应用都可能需要调试，但不想每个子应用都单独写一套加载逻辑。这时可以用工具的glob能力，把调试相关的脚本统一管理。

Vite中对应的是import.meta.glob：

const debugModules = import.meta.glob('./debug/*.js'); export async function enableDebugModules(params) { const tasks = Object.values(debugModules).map((loader) => loader()); await Promise.all(tasks); // 在这些模块里，可以各自 import('vconsole') 再做自己的初始化 }

Webpack对应的则是require.context：

const debugModules = require.context('./debug', false, /\.js$/); export function enableDebugModules() { debugModules.keys().forEach((key) => { debugModules(key).default?.(); }); }

这种方式不是为了加载VConsole这一个文件，而是把“动态加载VConsole”和“动态加载业务调试工具”捆绑在一起。举个例子，我在负责一个可视化关系图谱项目时，那个图需要支持上钻下钻动态加载数据——每次从某个节点钻取下一层，都要新请求接口、渲染新子图，数据量一多，渲染性能问题就特别难排查。当时我就是把所有调试面板（VConsole、性能监控、网络拦截器）都放到debug/目录下，用glob统一注册，然后在路由切换时判断是否需要动态唤起这批工具。这样做的好处是：调试资源的加载和业务模块解耦，你完全可以在线上事故发生时，通过一个链接参数让所有调试工具瞬间全部上线。

3. 加载时机的设计：不能只会“页面启动就加载”

很多人做动态加载，就写一个if (location.href.includes('debug')) import('vconsole')然后在页面顶层执行，这当然也算动态加载，但太糙了。时机设计得好，能把VConsole从“调试工具”升级成“线上巡检神器”。下面说几种我自己实际用过的方案。

3.1 URL参数精确控制开关

这是最基础也是最稳的方案。约定一个特殊而且不容易被用户手滑带上的参数，比如?vconsole=1或?debug=1，页面初始化时解析这个参数，存在则调用loadVConsole()。

function isVConsoleParamEnabled() { const params = new URLSearchParams(window.location.search); return params.get('vconsole') === '1' || params.get('debug') === '1'; } async function init() { if (isVConsoleParamEnabled()) { const { loadVConsole } = await import('./lib/debug/loader'); await loadVConsole(); } // 其他业务初始化... }

这里有个细节：解析参数的位置越靠前越好。最好在<head>里内联一段小脚本就判断完，决定是否给<html>加一个class="debug-mode"，后续所有模块都可以根据这个类名做差异化逻辑。比如打印更详细的日志、在界面上显示隐藏的调试标线、改变接口超时时间等等。

3.2 环境变量与构建模式的分层控制

如果你希望开发环境一定加载VConsole，测试环境默认不加载但可通过参数打开，生产环境只允许特定路径打开，那就需要分环境控制。这里很多人会犯一个错：直接用process.env.NODE_ENV判断，然后写死if (process.env.NODE_ENV === 'development')，结果传到测试阶段的构建时还是production，加载逻辑就废了。

更合理的做法是自定义一个环境变量，比如VITE_ENABLE_VCONSOLE，在.env.development里设成true，.env.test里设成false，.env.production里也设成false。然后在代码里读取：

// Vite 写法 if (import.meta.env.VITE_ENABLE_VCONSOLE === 'true') { loadVConsole(); }

关键点在于：把“是否强制开启”和“是否允许通过参数开启”拆成两个维度。我常用的设计是这样的：

import { loadVConsole } from './debug/loader'; const CONFIG = { // 环境是否默认开启 enableByDefault: import.meta.env.VITE_ENABLE_VCONSOLE === 'true', // 是否允许通过 URL 参数开启 allowByQuery: import.meta.env.VITE_ALLOW_VCONSOLE_QUERY === 'true', // URL 参数名 queryKey: 'vconsole', }; async function initDebugger() { const query = new URLSearchParams(window.location.search); const queryEnabled = CONFIG.allowByQuery && query.get(CONFIG.queryKey) === '1'; if (CONFIG.enableByDefault || queryEnabled) { await loadVConsole(); } }

这样配置的好处很直接：不同环境只需要改环境变量文件，不用再动代码。开发环境enableByDefault=true，每天打开页面就能看到调试面板；测试环境enableByDefault=false但allowByQuery=true，测试同学遇到问题直接加参数复现；生产环境enableByDefault=false，如果不小心把参数泄露出去，也不会默认开启。如果更严格，可以再加一层登录态或token校验，但这对多数情况来说已经足够了。

3.3 特定设备与用户行为触发

有些场景不想依赖URL参数。比如你正在线下跟客户演示，页面跑在客户自己的手机上，你要快速调console又不想让对方看到地址栏改参数，那手势触发就特别有用。常见的有：

• 摇一摇：通过devicemotion事件监听加速度变化，连续三次超过阈值就开锁。
• 连点5次：在页面Logo上连点5下，触发开关，这个在支付宝小程序和移动端浏览器里比较常见。
• 长按3秒：对某个不可见的区域长按。

摇一摇的实现网上有很多，但要注意权限问题：现在部分手机浏览器对DeviceMotionEvent需要requestPermission授权，直接监听没反应。所以我的落地经验是：手势只是个加点趣味性的触发源，兜底一定要有URL参数。万一手机不支持手势，就手动改地址加个?debug=1，不能完全依赖单一手段。

另一个实用性更强的触发源是“特定设备”。这里不是指在线下流程中硬编码机型，而是指把测试设备的UUID或IP做成配置下发。比如你的内部配置平台允许你配置某个IMEI或MAC（对于移动端可能不太好拿，但可以用UA或deviceId），在页面检测到当前设备命中了名单，就自动加载VConsole。这在做真机远程调试、灰度环境故障排查时非常有用——你可以直接让现场测试的手机自动跑调试模式，不需要任何手动操作。

4. 动态加载后的那几个真实踩坑现场

方案想得再好，实际落地时坑也不少。这一章我按照真实排错顺序，把你最可能遇到的几个问题摊开说。

4.1 实例重复创建：同一个页面出现两个悬浮球

动态加载最常见的问题就是new VConsole()执行了两次。这通常发生在：你在路由A进入时加载了一次，没有保留实例引用；然后在某个按钮事件里又加载一次；或者SPA里路由切换时同一个组件被重复挂载。

表象就是页面上出现两个悬浮球（甚至更多），点开之后面板互相遮盖，数据乱糟糟的。原因是VConsole构造器并不会自动检测全局是否已有实例，它只管往页面上塞元素和绑定事件。

我的解法分两层。第一层是全局单例排查：

if (!window.vConsole) { window.vConsole = new VConsole(); }

但这只防住了“同一个页面上下文”的情况。如果你在history模式的路由切换里写逻辑，每次进入都new VConsole，那旧的那个其实还存在。更稳妥的方案是：在动态加载前先判断，如果已存在就销毁旧的。VConsole官方并没有暴露一个完美的destroy方法，但是可以手动清理：

function destroyVConsole() { if (!window.vConsole) return; try { window.vConsole.destroy(); // 部分版本支持 } catch (e) { // 兜底：手动删除 DOM document.querySelector('#__vconsole')?.remove(); } delete window.vConsole; }

实测下来VConsole 3.3.0以上版本是支持destroy()的，但如果你用的是老版本，就只能手动把它的容器DOM（通常是#__vconsole）移除。它的JS事件监听由于绑在元素上，元素移除了，事件也会跟着消失。

4.2 执行时机的“真空期”：业务加载完了才看到面板

动态加载是异步的，意味着你在页面初始化时发起loadVConsole()，它要下载、解析、执行，这一段时间业务代码可能已经跑了好几步了。比如页面启动就发了一个请求/api/user/info，VConsole面板打开后，Network面板里可能看不到这个请求，因为它的请求记录是从VConsole初始化之后才开始的。

这个问题的本质是VConsole无法捕获它自己加载之前的网络请求和log。没有完美的补录方案，但有几个折中办法：

1. 把加载时机尽量提前：不要等DOMContentLoaded，直接在入口文件最顶部就loadVConsole()。如果用了import()，它既然异步了，就让它尽早发起，反正不阻塞主流程。
2. 手动补录关键日志：动态加载完成后，把提前存储的日志塞进去。配合一个自写的logs缓存数组：

const earlyLogs = []; window.earlyLog = (level = 'log', ...args) => { earlyLogs.push({ level, args, time: Date.now() }); }; // 在 loadVConsole 成功后 function replayLogs(vConsole) { earlyLogs.forEach(({ level, args, time }) => { if (vConsole && vConsole.log && typeof vConsole.log[level] === 'function') { vConsole.log[level](`[${new Date(time).toLocaleTimeString()}]`, ...args); } }); earlyLogs.length = 0; // 清空 }

这招有点“作弊”的味道，但确实能在关键时刻帮你定位问题。比如你要排查“页面首屏请求失败”的原因，业务代码在VConsole就绪之前就console.error了，VConsole面板上永远看不到。用这个缓存+补录的思路，就能在面板打开后看到完整的首屏报错。

4.3 样式被VConsole样式污染，或者被全局样式污染

VConsole会动态插入自己的CSS。如果项目里你的全局样式写得比较“激进”，比如把所有div的box-sizing设为border-box，或者给所有元素设了* { transition: all 0.3s }，那VConsole面板的UI可能出现错位、滚动卡顿、动画掉帧。反过来，如果VConsole的样式在某种层级下没盖住你的业务样式，悬浮球或面板也会变形。

踩过几个具体的坑：

• 你的项目用了@import或CSS-in-JS，并且在body上设置了font-size为16px，VConsole用的是rem有可能是相对于html的，乘以你的整体rem基准后会变得巨大。解决方式是给VConsole容器加独立的font-size重置，或者直接看它DOM结构，在自研样式里覆写。
• VConsole的悬浮球z-index默认可能是99999999，但仍然可能被你的弹层、React Portal节点盖住。因为它默认挂载在document.body下，你的弹层如果也是body下的且z-index更高或层级顺序靠后，就会盖住它。解决办法是在VConsole初始化后给它的根元素设置内联z-index：document.querySelector('#__vconsole').style.zIndex = '2147483647'。
• 如果你在移动端还开了-webkit-text-size-adjust之类的属性，面板里的字号可能突然变大，这是被viewport的字体缩放影响，可以强制设置VConsole内部的font-size: 14px !important。

总之，动态加载VConsole之后，样式问题不是“不用管”，反而更有可能出现。因为它插入CSS的时间点晚，跟业务样式的优先级较量会更明显。我的通用做法是：在加载完成后统一修正一遍。

4.4 动态加载与CSP（内容安全策略）的冲突

现代站点基本都有CSP响应头。如果你的线上Content-Security-Policy里设置了script-src 'self' 'unsafe-inline'，那你动态创建script标签或者动态import某些CDN地址时，极有可能直接被拦截。尤其是当你把vconsole.min.js放在自己的CDN或第三方CDN时，你得确认它的域名是否在CSP白名单里。

我在一个安全要求较高的运营后台项目里就踩过这个：平时线上不允许加载任何外部脚本，连style-src 'unsafe-inline'都是关掉的。动态加载VConsole的脚本在本地能跑，一上线就报Refused to load the script ... because it violates the following Content Security Policy directive。

解决思路有三个：

1. 把vconsole.min.js放进项目静态资源目录，作为self的一部分，这样如果CSP允许'self'就能加载。
2. 给VConsole脚本单独加nonce或hash。也就是在CSP里为这个特定脚本生成一个hash，然后请求时带上去。这个更适合script标签动态注入场景，但你需要每次都计算hash，VConsole文件改个字节就得重算，比较麻烦。
3. 如果项目有白名单机制，就把你的CDN域名加进去，但注意这等于给页面开了一个外部脚本的口子，有安全风险。

最稳妥的方式其实是在构建阶段把vconsole.min.js打进产物里，比如放到public目录下，然后在运行时通过相对路径加载。由于同源，不违反CSP的'self'限制。这样就绕开了CDN的跨域和CSP双重问题。

4.5 加载完成后自动打开面板

有线上排查需求时，我们不希望VConsole加载完还是一个折叠的悬浮球，想让它直接展开面板。VConsole提供了showPanel()方法，但刚初始化完立刻调用有时会失败，因为它的DOM还没完全生成。写的时候要注意时序：

async function loadVConsole() { const { default: VConsole } = await import('vconsole'); const vConsole = new VConsole(); await nextTick(); // 模拟等待DOM渲染 vConsole.showPanel(); // 默认打开Log面板 }

在Vue里可以用await nextTick()，React里可以用setTimeout(..., 0)。实际测试发现有时需要setTimeout两次才稳定，因为VConsole内部有一些动画过渡。我采用的方式是：

const openPanel = (vConsole, retries = 3) => { try { vConsole.showPanel(); } catch (e) { if (retries > 0) setTimeout(() => openPanel(vConsole, retries - 1), 100); } };

这种带重试的策略，基本能保证面板一定展开。

5. 进阶：把VConsole变成自己团队的“临时工”

如果能做到前面这些，你其实已经掌握了一套比较完整的动态加载方案了。但作为老手，我建议你再往前走一步：不要每次都从零写loadVConsole()，而是把它沉淀成一个独立的调试工具加载器，结合团队业务做扩展。

5.1 封装一个可复用的调试加载器

我平时会在项目里维护一个src/debug/index.js，对外暴露几个函数：

import { loadVConsole } from './loadVConsole'; import { bindGestureTrigger } from './gesture'; import { getDebugConfig } from './config'; /** * 初始化调试工具，返回一个 Promise<boolean> * 表示本次是否成功启用了调试模式 */ export async function initDebugTools(options = {}) { const config = getDebugConfig(); const enable = config.enableByDefault || options.queryEnabled || options.forceEnable; if (!enable) return false; const vConsole = await loadVConsole(); bindGestureTrigger({ onTrigger: () => vConsole.showPanel() }); // 可以再加一个项目自定义的日志面板插件 if (options.customPlugin) { vConsole.addPlugin(options.customPlugin); } return true; }

这样沉淀下来后，任何一个新页面想开启调试，只需要在入口文件里调用一行：

import { initDebugTools } from '@/debug'; initDebugTools();

至于URL参数、环境变量、手势绑定这些逻辑，全都被封装起来了，新人不看源码也能用。

5.2 和业务日志上报打配合

VConsole本身是纯前端的调试工具，但很多时候我们需要把console日志、网络请求日志上报到服务端，辅助远程排查。动态加载VConsole之后，可以顺便把全局的window.onerror、unhandledrejection、fetch的响应拦截都挂在VConsole上，同时打一份到服务器。

一个比简单更好用的做法是：在VConsole加载成功后，给VConsole的log方法做一个包装，所有通过VConsole面板看到的日志，同时复制一份到上报队列：

function proxyConsoleToReporter(vConsole) { const methodList = ['log', 'warn', 'error', 'info', 'debug']; methodList.forEach((method) => { const original = console[method]?.bind(console); console[method] = (...args) => { original?.(...args); // 上报逻辑，注意这里要做序列化处理 reportLog({ method, message: args.map(serialize), time: Date.now() }); }; }); }

这样你线上排查时，即使当时没开VConsole，也能在服务端日志里捞出症结。等后台查到问题，再让现场人员动态加载VConsole摆弄细节，效率会高很多。

5.3 离线包/H5容器里的特殊姿势

如果你是做App内嵌H5，而且页面跑在离线包环境，那上面说的“从CDN加载vconsole.min.js”基本是行不通的——离线包根本不会实时请求外网CDN。这种场景下，vconsole.min.js应该内置在包里，路径也用相对路径，离线包指定根目录加载时才能命中。

另一种思路是：把VConsole的JS代码内联到主包里，但用运行时启用来控制是否new VConsole()。这种本质上也算动态加载——代码在包里，但是实例化是动态的，不在初始化时不创建面板，对内存和性能影响很小。

做法其实很简单：

import VConsole from 'vconsole'; // 代码打包进主bundle export function enableVConsole() { if (!window.vConsole) { window.vConsole = new VConsole(); } }

这个方案虽然牺牲了一部分bundle体积，但对于“离线包优先”的App来说，远比从远程加载更可靠。换句话讲，所谓“动态加载”不一定是“代码不进包”，而是“代码不生效”，只要能保证用户不会在非预期场景下看到调试入口，方案就是合格的。

5.4 性能到底省了多少：一次实测对比

说了这么多，直接上数据。我在一个典型的管理后台SPA项目里做了对比：

• 不引入VConsole：首屏JS总大小约 1.2MB，页面可交互时间约 1.8s（中档Android真机）。
• 在入口用import VConsole from 'vconsole'全局引入：首屏JS总大小约 1.7MB，页面可交互时间约 2.6s。
• 用import('vconsole')动态加载且不触发：首屏JS总大小约 1.2MB，页面可交互时间约 1.8s，跟不引入几乎一样。vconsole的chunk（约500KB）只有在触发时才被拉取。

这个对比很直观：全局import会把VConsole的代码合并到主包或一个同步chunk里，必须在首屏执行；动态import则是把它放到异步chunk里，浏览器只有在执行到这行代码时才去请求这个chunk。节省的不只是体积，更是首屏关键路径上少了一段JS的解析和执行时间。

如果担心触发时才拉取导致等待时间太长，你可以用prefetch或preload提前把chunk下载下来，但不执行。这就涉及构建工具的进阶配置了，Vite里可以配合import(/* @vite-ignore */)自己控制，也可以使用HTML link标签的rel=prefetch。我觉得对于VConsole来说，如果针对的是可能用到的调试场景，用普通异步chunk就够了，不用额外preload，因为调试场景本身容错度高，慢半秒没人在意。

6. 最后说几句掏心窝的

动态加载VConsole这件事，本质上是一个“工具是否应该常驻生产”的意识问题。很多项目上线带着VConsole跑，倒也不是因为开发者菜，而是压根没想过它会带来什么影响。真正在移动端把一批真实用户跑起来，你才会意识到悬浮球碍眼、点击误触、bundle变大这些事有多影响体验。

我个人的习惯是这样的系列工程思维落地后，再去接新的H5项目，调试工具的加载策略几乎成了基础工程的一部分。前端工程化永不止于把代码分开、压缩、缓存，也包括把“开发辅助工具”这类不该出现在生产环境的资源管住。你可以不写那么多花哨的加载器，但一定得有一个明确的态度：调试工具默认不出现，需要时能一秒召唤。

另外提醒一句：VConsole能帮你看到console和网络请求，但它帮不了你发现代码为什么会崩溃。动态加载做得再完善，也不代表业务本身没有bug。别把调试面板当成遮羞布，该重构的代码趁早重构。

这期的方案基本覆盖了我做前端这几年遇到的大部分场景，从老项目到新工程、从开发环境到生产环境、从URL参数到手势触发再到离线包，你可以根据自己的实际情况挑两三种组合着用。如果在实践中遇到新的怪问题，再回到那三个原则——防重复、控时机、管样式——基本都能找到方向。