Webpack多页面entry通过glob.sync自动扫描src/pages/*/index.js路径生成，提取唯一合法name作为chunk名和HTML文件名，并动态创建HtmlWebpackPlugin实例注入对应资源。
Webpack 多页面 entry 怎么自动识别目录结构
手动写死 entry 对象在页面数增长后会迅速失控，必须靠文件系统扫描动态生成。关键不是“能不能”，而是“扫什么、怎么命名、怎么避免冲突”。
- 推荐路径模式：
src/pages/*/index.js（每个子目录一个入口），用glob.sync()获取所有匹配路径 - 提取 name 时别直接用文件名，要统一规则：比如
filePath.match(/\/pages\/([^/]+)\//)[1]，否则遇到user-center/index.js和user/profile/index.js会重名 - name 将作为 HTML 文件名、JS chunk 名、
HtmlWebpackPlugin的chunks参数依据，必须唯一且合法（不能含/、空格、中文） - 如果存在同名但不同端的页面（如
login_pc和login_h5），建议在 name 中保留后缀，并在模板中通过process.env.TARGET控制逻辑分支
HtmlWebpackPlugin 如何为每个页面生成独立 HTML
一个 HtmlWebpackPlugin 实例只生成一个 HTML，多页面必须实例化多个——但不能硬编码，得配合 entry 动态构造。
- 每个实例的
template应指向对应页面的src/pages/{name}/index.html，而不是共用一个模板 -
filename必须按需设置：生产环境建议用{name}/index.html（保持语义路径），开发环境可用{name}.html避免嵌套访问问题 -
chunks字段必须精确指定该页面依赖的 entry key，例如chunks: ['login']，漏掉会导致 JS 不加载，多写会导致冗余请求 - 如果某页面需要额外注入变量（如 SEO 标题、meta 描述），可通过
templateParameters传入对象，再在 HTML 模板里用渲染
publicPath 和 base 路径不一致会导致哪些 404
资源路径错位是静态部署中最隐蔽的 404 来源，根源常在于构建配置与服务器部署路径脱节。
-
publicPath（Webpack）控制 JS/CSS/图片等资源的 URL 前缀；base（Vite）作用类似，但 Vite 还影响路由前缀；两者都必须和实际访问路径一致 - 常见错误：本地开发用
publicPath: '/'，但部署到https://example.com/myapp/，却没改成'/myapp/'，结果所有js/app.js请求变成https://example.com/js/app.js（404） - 更隐蔽的是图片：用
import logo from './logo.png'会被重写路径，但写死<img src="logo.png">不会，后者永远走相对路径，容易在子目录部署时挂掉 - 验证方法：打开打包后的
dist/index.html，检查所有src和href属性是否带正确前缀；再用浏览器开发者工具 Network 面板看资源请求地址是否合理
差分部署时如何避免覆盖其他页面的资源
多页面项目上线频率不一，经常只需更新其中一两个页面，但默认打包会全量覆盖 dist 目录，极易误删他人资源。
立即学习“前端免费学习笔记（深入）”；
- Webpack 默认输出是覆盖式写入，没有“增量更新”概念。真要差分，得靠构建后脚本：先读取旧
dist目录结构，再只拷贝本次变更的页面子目录（如dist/login/、dist/about/） - 关键前提是：每个页面的资源必须物理隔离——JS/CSS/图片全部放在各自
dist/{name}/下，不能混在根目录或公用static/里 - 借助
output.filename和output.chunkFilename设置路径，例如js/[name].[contenthash:8].js，确保 hash 变化仅反映本页面代码变更 - CDN 场景下更要谨慎：若用同一 CDN 域名，旧资源可能被缓存，新 HTML 引用新 hash 文件没问题，但若某页面未重新构建，它仍引用旧 hash，而旧文件已被清理——这就需要服务端配置缓存策略或保留历史版本
publicPath 自动改写，一旦部署路径变动，就只能靠人工 grep + 替换，或者加构建后校验脚本兜底。 
