生产环境怎么自动移除或禁用 Mock.js

一、核心认知：为什么不能只在运行时“关掉” Mock？

很多开发者在初次遇到该问题时，往往倾向于在应用入口文件（如 main.ts 或 main.js）中加上一个运行时开关变量：

// ⚠️ 典型错误示范：仅在运行时进行分支阻断
import './mock'; // 静态顶层导入

if (window.__ENABLE_MOCK__) {
  console.log('启用模拟数据');
}

这种写法存在极为严重的隐患。从前端打包与运行时原理来看，它完全无法达到“生产环境禁用 Mock”的安全与性能要求：

• 全局 XMLHttpRequest 劫持不可逆：静态 import './mock' 或 import 'mockjs' 属于 ES Module 规范中的顶层声明。当浏览器或打包器执行到这行代码时，Mock.js 内部的初始化代码会立刻自执行，将原生 window.XMLHttpRequest 替换为其自定义的包装类。即使你后续一条 Mock 路由都没有注册，全局的网络底座已经被它污染篡改了。
• 无法享受 Tree-Shaking 优化：静态 import 在打包分析依赖图谱时具有最高优先级。无论你后续代码中是否调用 Mock 的任何方法，打包工具都必须将 Mock.js 核心库及其引用的所有本地 mock 数据模板、虚拟字段全部打包进生产产物中，凭空造成 30KB~100KB+ 的体积虚增。
• 敏感业务结构与测试数据泄露：开发阶段在 mock 目录中编写的测试账号、手机号、模拟接口字段甚至未公开的管理端业务结构，会直接被打入静态 JS 资源中，极易被逆向分析，带来安全合规风险。

二、方案一：基于环境变量的编译期代码消除（DCE）

自动化移除的核心机制在于：让打包工具在编译期就能将环境变量识别为静态字面量常量。当判断条件恒为 false 时，Terser、Rollup 或 esbuild 等压缩优化工具会在生成最终 AST 时直接将整段代码剪除，并且连同代码块内引用的模块一起从打包依赖图中剔除。

1. Vite 规范做法（基于 import.meta.env）

在 Vite 工程中，官方提供了内置的预设常量 import.meta.env.DEV（在 vite build 生产构建时恒为布尔值 false）。我们需要配合 ES 动态导入（Dynamic Import） 完成按需加载：

// src/main.ts
import { createApp } from 'vue';
import App from './App.vue';

// 仅在本地开发模式下动态载入 Mock 模块
if (import.meta.env.DEV) {
  await import('./mock');
}

const app = createApp(App);
app.mount('#app');

2. Webpack / Vue CLI 规范做法（基于 process.env.NODE_ENV）

在基于 Webpack 或 Vue CLI 的项目中，Webpack 默认通过内置的 DefinePlugin 将代码中的 process.env.NODE_ENV 替换为带引号的字面量字符串 "production"。因此我们利用条件语句结合 CommonJS require 或动态 import()：

// src/main.js
import Vue from 'vue';
import App from './App.vue';

// 在生产构建时，该代码会被编译替换为 if ("production" === 'development')
// Terser 优化器识别后会直接将整个 if 分支及内部模块彻底消除
if (process.env.NODE_ENV === 'development') {
  require('./mock');
}

new Vue({
  render: (h) => h(App),
}).$mount('#app');

三、方案二：构建工具层面的物理隔离（防误打包兜底）

在多人协同的大型团队开发中，纯靠团队约定的代码级规范存在风险：某位团队成员可能因疏忽在某个业务组件中直接写了 import Mock from 'mockjs'。为了杜绝此类人为失误，最稳妥的做法是在构建配置文件中设置物理级拦截。

1. Vite 推荐方案：配置 vite-plugin-mock

如果项目使用社区标准的 vite-plugin-mock，可以在构建配置中通过命令参数或环境开关彻底关闭生产注入：

// vite.config.ts
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import { viteMockServe } from 'vite-plugin-mock';

export default defineConfig(({ command, mode }) => {
  const isDev = command === 'serve';

  return {
    plugins: [
      vue(),
      viteMockServe({
        mockPath: 'mock',
        localEnabled: isDev,        // 仅在本地开发服务器启动时启用
        prodEnabled: false,         // 严禁在生产打包时注入 mockjs 依赖
        injectCode: ``,             // 生产代码注入置空
      }),
    ],
  };
});

2. Webpack 推荐方案：别名重定向（resolve.alias）到空模块

通过配置 Webpack 的模块解析别名，如果当前构建环境是 production，强制把对 mockjs 的所有解析请求重定向到一个只有 export default {} 的空文件，或者直接映射为 false：

// vue.config.js 或 webpack.config.js
const path = require('path');
const isProd = process.env.NODE_ENV === 'production';

module.exports = {
  configureWebpack: {
    resolve: {
      alias: {
        // 当处于生产环境时，所有对 mockjs 或 mock 目录的引用都指向空模块
        ...(isProd ? {
          'mockjs': path.resolve(__dirname, 'src/utils/emptyModule.js'),
          '@/mock': path.resolve(__dirname, 'src/utils/emptyModule.js')
        } : {})
      }
    }
  }
};

创建 src/utils/emptyModule.js：

// 这是一个安全的占位空模块
export default {
  mock: () => ({}),
  setup: () => ({}),
  Random: {}
};

这种物理重定向相当于给整个工程上了“安全保险栓”。即使有新员工在代码中误用了全局 Mock 导入，生产打包时实际引入的也只是几字节的空对象，既不占体积，也不会劫持浏览器的原生网络栈。

四、进阶演进：从客户端侵入转向零侵入式 Mock

从技术架构演进的角度来看，在前端浏览器端运行 Mock.js 本质上属于一种高侵入式方案。随着现代开发工具链的成熟，更推荐的工程实践是转向“网络层真实代理”或“服务工作线程拦截”：

五、构建结果验证与防漏排查方法

完成配置后，必须在发布流水线或本地构建输出中建立确凿的验证手段，杜绝“以为关了，其实还在”的假象。

1. 产物依赖图谱检索（Bundle Analyzer）

在构建打包时开启分析插件（Vite 使用 rollup-plugin-visualizer，Webpack 使用 webpack-bundle-analyzer）。打包完成后在浏览器打开生成的 HTML 分析报表：

• 在报表搜索框中全局检索 mockjs。
• 验证结果应当为：未找到任何匹配模块（0 命中）。
• 如果依然搜索出 mockjs，可在图谱中点击追踪其依赖链（Parent Chunk），定位是哪一行代码静态引入了它并将其修改为动态导入。

2. 浏览器运行时指纹检测（生产冒烟测试）

将打包后的 dist 产物通过本地静态服务器预览（如执行 npx serve dist 或 vite preview），在浏览器打开开发者工具（Console 控制台），运行以下断言代码：

// 检查 XMLHttpRequest 构造函数是否为浏览器原生实现
console.log(window.XMLHttpRequest.toString());

// 正确的原生输出结果：
// "function XMLHttpRequest() { [native code] }"

// 若输出为类似于以下内容，则说明 Mock.js 仍被打包并执行了：
// "function () { ... }" 或包含 "MockXMLHttpRequest" 标识

3. CI/CD 自动化流水线门禁脚本

为了保证团队提交代码不产生回退，可以在持续集成（CI）构建脚本中加入一道简短的静态扫描指令：

# 打包构建
npm run build

# 扫描 dist 产物中是否包含 mockjs 特征字符串
if grep -ri "mockjs" dist/ > /dev/null; then
  echo "❌ 严重错误：生产构建产物中检测到 Mock.js 残留代码，已终止发布流水线！"
  exit 1
else
  echo "✔ 验收通过：生产产物纯净无 Mock.js 模块。"
fi

六、常见踩坑与技术选型决策对照

在实际落地过程中，还有几个极易忽视的细节需要留意：

• 踩坑 1：TypeScript 类型声明与打包警告：在 TypeScript 项目中使用 import('./mock') 可能会提示类型错误。请确保在 tsconfig.json 的 compilerOptions 中将 "moduleResolution" 设置为 "node" 或 "bundler"。
• 踩坑 2：异步组件首屏渲染时差：由于 await import('./mock') 是异步载入的，在本地开发环境如果网速较慢或本地电脑卡顿，可能会出现页面优先挂载而 Mock 规则还未完成初始化的瞬时请求失败。建议在开发环境下将应用挂载函数放置在 setupMock().then(() => app.mount('#app')) 中，确保初始化时序严谨。

总结实施建议

生产环境移除 Mock.js 的最佳实践遵循“编译期剪枝为主，构建配置兜底为辅，逐步迁移至零侵入中间件”的原则：

1. 快速治标：将现存项目的静态 import './mock' 统一改为 if (import.meta.env.DEV) { await import('./mock'); }（Vite）或 if (process.env.NODE_ENV === 'development') { require('./mock'); }（Webpack）。
2. 工程防御：配置 resolve.alias 映射空模块或配置插件 prodEnabled: false，从编译底层阻断遗漏风险。
3. 长期演进：新功能模块联调优先采用基于本地 DevServer 的代理或中间件 Mock，使前端生产与开发代码完全共享纯净的真实网络协议栈。