如果你在搜索引擎输入“Webpack 5 DDoS Protection”，很可能会看到一些资料把缓存优化、代码分割等构建能力直接称作 DDoS 防护。严格来说，Webpack 5 官方更新列表里并没有 DDoS Protection 这一项，它也不是安全软件。Webpack 的职责是在开发阶段把模块打包成浏览器可运行的静态资源，它运行在构建机上，不参与线上请求的转发或过滤。DDoS 攻击则发生在运行时，攻击者通过海量请求占用带宽、连接数和计算资源，使服务不可用。两者处在完全不同的技术层面。

一、为什么 Webpack 5 没有原生 DDoS Protection 特性

DDoS 防护通常部署在流量进入业务服务器之前，常见的形态包括运营商黑洞清洗、高防 IP、CDN 边缘节点、WAF 以及 Nginx 等接入层的限速模块。它们的共同点是运行在请求路径上，能够基于 IP、请求频率、报文特征等维度丢弃恶意流量，保护后端的带宽和计算资源不被耗尽。

Webpack 5 的工作范围完全不同。它读取本地文件系统中的模块和依赖，经过 loader、plugin 转换后输出静态资源。这个阶段没有网络流量经过它，也不会对用户请求做出任何仲裁。即便使用 webpack-dev-server，它只是一个开发环境使用的静态文件服务器，官方文档明确不建议直接暴露到生产环境，更没有任何抗 DDoS 能力。

因此，把“Webpack 5 新特性”和“DDoS Protection”放在一起，大概率是对某项优化能力的误读，或者是为了吸引点击而简化了概念。下面用一张表对比两者的边界。

二、Webpack 5 中容易被误解为防护能力的构建优化

Webpack 5 引入的持久化缓存是一项非常实用的改进。通过把模块依赖图、编译结果缓存到文件系统，二次构建可以跳过大量重复计算，尤其对于大型项目，热更新和 CI 构建的 CPU 占用会明显下降。这通常能缓解开发服务器在频繁编译时的负载，但它的作用域仍然在开发机和构建机内部，并不处理线上流量。

另一个经常被扯上安全关系的是 output.filename 中的 contenthash。使用 contenthash 后，文件内容不变，文件名中的哈希就不会变化；一旦内容变化，文件名也随之更新。这种强缓存策略可以让 CDN 和浏览器长期缓存静态资源，减少重复请求和回源次数。如果源站带宽有限，这确实能降低每次页面访问带来的资源传输压力，但从攻击角度看，它并没有阻止请求到达 CDN 或源站。

splitChunks 和 tree shaking 也是类似道理。splitChunks 把公共依赖拆成独立 chunk，避免每个页面重复加载相同代码；tree shaking 则移除未使用的模块，减小总体积。它们共同减少了用户下载的数据量，也减少了源站传输的字节数，但这些属于性能优化范畴，不是安全特性。

下面是一个 Webpack 5 中开启文件系统缓存、contenthash 和 splitChunks 的配置示例：

// webpack.config.js
module.exports = {
  cache: {
    type: 'filesystem',
  },
  output: {
    filename: 'js/[name].[contenthash:8].js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
        },
      },
    },
  },
};

这段配置会让构建产物带上稳定哈希，并把第三方依赖拆分为独立缓存文件。对于真实用户来说，第二次访问时大部分资源命中的是缓存；但对于攻击流量来说，这些优化并不会验证请求来源，也不会限制请求频率。

三、为什么这些优化不能替代 DDoS 防护

DDoS 攻击关注的不是单次请求能传输多少字节，而是能否在短时间内建立大量连接或发送大量请求，从而占满带宽、文件描述符、数据库连接或 CPU 时间。攻击者可以直接向源站 IP 发起请求，即使静态资源全部缓存在 CDN，源站仍然需要处理 DNS、TLS 握手和回源请求。如果攻击者控制肉鸡绕过 CDN 直接打源站 IP，所有前端缓存优化都会失效。

即便攻击流量经过 CDN，也不代表风险消失。CDN 会按照请求数和流量计费，若没有配置 WAF、限速或封禁策略，大量请求仍然会消耗带宽额度，并可能触发回源。一旦 CDN 出现大量缓存未命中，请求会直接打到后端，造成真正的服务不可用。

另外，Webpack 只是构建工具，它无法识别请求是否来自僵尸网络，也没有运行时拦截能力。真正有效的 DDoS 缓解必须放在接入层和网络层，例如：

• 使用 CDN 隐藏源站真实 IP，只允许回源流量通过白名单；
• 在 DNS 或 CDN 上配置 WAF，拦截异常 User-Agent、高频 IP 和恶意路径；
• 在 Nginx 或网关层设置每 IP 请求速率限制；
• 对关键接口做令牌桶或漏桶限流，防止单点资源耗尽。

四、结合 Webpack 5 构建更抗压的前端资源

虽然 Webpack 5 不提供 DDoS Protection，但合理利用它的缓存和拆分能力，仍然可以降低源站在突发流量下的压力。第一步是让静态资源具备长期缓存条件：使用 contenthash，把第三方依赖拆分为独立 chunk，这样公共库文件可以长时间命中 CDN 缓存，减少重复传输。

第二步是把构建产物上传到对象存储或 CDN 源站，与动态 API 服务隔离。前端页面只需要从 CDN 加载资源，后端服务只负责必要的接口。这样即使接口层被打，静态资源仍然可访问；反之，静态资源流量压力也不会直接消耗后端数据库连接。

第三步是在接入层配置限速。下面是一个 Nginx 限流配置示例，它限制了每个 IP 每秒最多 10 个请求，并允许短暂突发：

# 在 http 块中定义限速区域
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
server {
    listen 80;
    server_name your-domain.com;
    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://backend;
    }
}

这段配置不会替代专业抗 DDoS 设备，但能作为第一道本地防线，过滤掉一部分高频请求。结合 Webpack 5 的持久化缓存和合理的 CDN 缓存策略，整体架构能够在突发流量到来时保留更多服务能力。

最后，监控和告警同样重要。你需要关注 CDN 带宽、回源请求数、后端 5xx 比例以及源站 CPU 使用率。如果发现某个静态资源被大量重复请求，可以单独调整缓存策略或增加边缘限速；如果攻击绕过 CDN 直接打源站，则应该立刻接入高防 IP 或更换源站 IP，而不是期望 Webpack 配置能解决所有问题。