
前端项目里，CSS 经常是最容易被低估、也最容易失控的一层。

功能开发阶段，大家通常更关注接口、状态、交互、性能；样式经常被视为“最后补一下”。结果项目做久了以后，最让人不敢动的反而是样式文件。

CSS 在项目里经常 问题表面看起来像“技术选型不对”，其实更常见的原因是边界不清。

## 样式为什么这么容易变脏

因为 CSS 默认就是全局生效、相互影响的。

这意味着只要你没有主动管理边界，就很容易出现：

- 修改一个类名影响多个页面
- 提高优先级去覆盖旧规则
- 新样式不断叠加补丁
- 组件样式和页面布局样式混在一起

写的时候都合理，叠久了就开始变乱。

## 最常见的反模式：为了解决一个问题，再加一层覆盖

项目里的 CSS 最终常常会演化成这样：

```css
.card-title {
  color: #333;
}

.page-a .card-title {
  color: #111;
}

.dialog .page-a .card-title {
  color: #000;
}
```

每一次覆盖都在解决眼前的问题，但长期看，其实是在提高整套样式系统的耦合度。

## 样式的职责要分层

一个更稳定的方式，是把样式按职责拆开，而不是全部混在一起。

常见可以分为：

- 基础样式
- 组件样式
- 页面布局样式
- 状态样式

基础样式负责：

- 重置
- 字体
- 颜色变量
- 间距变量

组件样式负责组件本身的外观。

页面样式负责页面结构和布局，不应该直接侵入组件内部细节。

## 命名不是形式主义

很多人觉得 CSS 命名规范只是团队洁癖，其实不是。

命名说到底是在表达边界。

比如：

- `.button`
- `.user-card`
- `.article-list__item`

这些名字会直接影响后来的人如何理解和使用这个样式。

如果命名过于模糊，例如：

- `.box`
- `.item`
- `.left`
- `.active`

那么后续维护者几乎只能靠猜。

## 不要让页面直接修改组件内部

一个很常见的问题是，页面层样式直接写到组件内部类名上。

例如某个页面为了调整卡片标题颜色，直接覆盖了组件里的 `.card-title`。这样虽然快，但组件边界已经被打破。

更稳的做法是：

- 通过 props 或变体控制样式
- 通过外层 class 控制布局
- 必要时提供明确扩展点

而不是让页面随便改组件肚子里的结构。

## 工具能帮忙，但不能代替设计

无论你用的是：

- CSS Modules
- Sass
- Tailwind CSS
- styled-components

它们都只能帮你管理样式，不会自动帮你设计边界。

如果结构本身就是乱的，换工具并不会根治问题。

稳定的样式系统，核心还是：

- 样式归谁管
- 哪一层能改哪一层
- 哪些是通用规范
- 哪些是局部特例

## 变量体系比复制颜色更重要

CSS 在项目里经常 维护难，不是规则复杂，而是设计令牌缺失。

例如颜色、边距、字号、圆角全部写死，后面你一旦想统一调整视觉风格，就会发现全项目到处散落着重复值。

比起不停复制 `#333`、`16px`、`8px`，更应该做的是先建立变量。

## 写在最后

CSS 可维护性的关键，不在于选了多高级的方案，而在于有没有把样式边界设计清楚。

只要职责明确、命名清晰、组件和页面各守边界，样式就会越来越稳；反过来，如果一切都靠覆盖和补丁推进，再现代的技术栈也救不了后期失控。


CSS 可维护性实践：样式失控通常不是技术问题，而是边界问题


提到前端打包优化，很多人的第一反应是：

- 开 gzip
- 开 brotli
- 做压缩
- 分包

这些都重要，但它们更多是结果优化，而不是根因优化。

项目包体积越来越大，并不是因为压缩没做好，而是因为依赖结构、代码组织和资源策略本身就不够克制。

## 先弄清楚体积到底是怎么长起来的

一个前端包变大，常见来源通常有：

- 引入了过大的第三方库
- 首屏加载了本不该首屏加载的代码
- 公共依赖拆分不合理
- 图片、图标、字体资源过重
- 工具函数或组件重复打进多个 chunk

如果不先定位来源，只盯着构建配置调参数，优化通常很快进入瓶颈。

## 不要把“功能能跑”当成依赖引入标准

很多包体积问题，都是从一行 import 开始的。

比如为了一个简单功能，引入一个很重的库；或者只需要某个小工具函数，却把整个工具库一起打进来。

这类问题最常见，也最容易被忽视，因为功能层面完全没问题。

但从长期看，依赖使用要有一个基本原则：

引入的不是“功能”，而是“长期成本”。

## 路由级拆分是最基本的一步

如果一个页面用户根本没访问，理论上它相关的代码就不应该在首屏里出现。

这也是代码分割最直接的价值。

对于多页面或后台系统来说，路由级拆分通常是最先该做的事情。它并不是锦上添花，而是把不必要的首屏负担拿掉。

## 组件级懒加载也要谨慎

有些团队在发现包大之后，会开始把很多组件都做成懒加载。

这不是不行，但要分场景。

如果组件本身很轻、用户几乎一定会看到，那为了“拆得更碎”而懒加载，收益未必大，反而会增加请求碎片和复杂度。

更适合懒加载的通常是：

- 富文本编辑器
- 图表模块
- 大型表格
- 低频弹窗
- 管理后台高级筛选面板

也就是说，真正重、真正低频的模块优先拆。

## 图片和图标常常是被低估的体积来源

不少人会盯着 JS 包，却忽略了静态资源。

实际项目里下面这些都很常见：

- 首页大图未压缩
- 多个页面重复加载大图资源
- 只需要几个图标，却引入整套图标包
- 字体文件过大

这些问题加起来，用户感知可能比 JS 包还明显。

## 公共代码不是越集中越好

做公共 chunk 拆分时，一个常见误区是：只要公共就全抽出来。

问题在于，如果一个公共 chunk 非常大，而其中大部分内容其实只服务少数页面，那它反而会成为新的负担。

所以公共代码拆分不是追求“集中”，而是追求“合理复用”。

## 分析工具一定要用

如果一个项目已经明显变重，最不应该做的事情就是靠猜优化。

这时最有效的办法通常是：

- 看 bundle 分析图
- 看每个 chunk 的组成
- 找出最大的第三方依赖
- 找出重复出现的模块

很多优化方向只要一可视化，就会非常明显。

## 真正长期有效的优化，往往是结构优化

例如：

- 避免滥引第三方库
- 限制公共模块膨胀
- 拆分高成本页面
- 减少重复资源
- 让低频功能延后加载

这些事情比单纯调构建参数更费脑子，但通常也更有长期价值。

## 写在最后

打包优化不是一场“把构建工具调到最极致”的比赛，而是一次对项目结构的体检。

压缩、分包、缓存当然重要，但真正决定包体积的，通常还是代码和依赖本身的组织方式。只要结构合理，很多优化会自然发生；如果结构混乱，再多构建技巧也只是延后问题爆发。


前端打包优化经验：包体积不是只靠压缩就能降下来的


不少团队都做代码评审，但做着做着会进入一个低效状态。

评审内容常常集中在：

- 分号要不要
- 命名够不够优雅
- 这一行能不能再简洁一点

这些问题不是完全没价值，但如果评审长期停留在这个层面，更重要的风险往往会被漏掉。

## 代码评审的目标不是“挑毛病”

更合理的理解应该是：

代码评审是在功能上线前，尽可能早地发现后续维护成本和行为风险。

也就是说，评审不只是看“能不能跑”，更要看：

- 改动边界是否清楚
- 逻辑是否容易出错
- 后面的人能不能接手
- 有没有引入新的复杂度

## 前端评审里更值得关注什么

### 1. 状态流转是否清晰

前端不少 bug，不是出在渲染，而是出在状态流转混乱。

例如：

- 一个状态被多个地方同时改
- 本地状态和服务端状态混在一起
- 提交流程和展示状态耦合

这类问题如果在评审阶段不看，后面会很难查。

### 2. 组件边界是否合理

一个组件是不是承担了太多职责，是评审里非常值得看的点。

如果一个组件同时负责：

- 请求接口
- 数据转换
- 展示渲染
- 弹窗控制
- 路由跳转

那即使当前能跑，后面也很容易变成维护热点。

### 3. 异常路径有没有考虑

很多代码在 happy path 下没有问题，但一旦接口失败、字段为空、数据延迟返回，就容易暴露问题。

评审时可以多问一句：

如果这里失败，会发生什么？

这句话比看十个命名细节更有价值。

## 不要把格式工具负责的事情留给人做

如果团队还在评审里花很多时间讨论：

- 缩进
- 引号
- 分号
- 单行还是多行

那说明很多事情还没有交给工具。

能自动化的风格问题，尽量自动化；评审时间应该用在更难自动发现的风险上。

## 评审评论要具体，不要抽象

“这里感觉不太好”“建议优化一下”这类评论，通常帮助不大。

更有效的评论方式是直接指出：

- 风险在哪里
- 为什么是风险
- 可能导致什么后果

例如：

“这里把接口状态和弹窗状态放在同一个对象里，后面如果弹窗有异步关闭逻辑，可能会让提交状态被意外覆盖。”

这种评论才真正能推动改进。

## 好评审也要控制范围

评审不是架构大会。

如果当前 PR 只是修一个 bug，而评审开始讨论整个项目状态管理方案，那很容易偏离主题。

一个比较稳的原则是：

- 优先看这次改动直接引入的风险
- 再看和当前改动强相关的结构问题
- 不相关的长期优化可以另开 issue

这样评审更聚焦，也更容易形成闭环。

## 写在最后

前端代码评审更有价值的地方，不在于把代码改得像教材，而在于提前暴露维护风险。

如果评审能多关注边界、状态、异常路径和长期复杂度，团队的代码质量通常会比单纯追求“写法漂亮”更稳定。真正好的评审，不是挑出最多问题，而是尽早发现最值得处理的问题。


前端代码评审怎么做才有效：不是挑语法，而是提前发现维护风险


前端项目一旦进入多人协作阶段，很多问题看起来像是 Git 问题，实际上往往是协作习惯问题。

例如：

- 提交信息看不懂
- 一个分支改动太大
- 冲突频繁
- 回滚困难

Git 本身并没有做错什么，问题通常出在团队怎么使用它。

## 提交粒度太大，是很多协作问题的起点

很多人习惯攒一堆改动再一起提交，结果一个 commit 里同时包含：

- 新功能
- 样式调整
- 文案修改
- 顺手重构
- 调试代码删除

这样的提交在自己脑子里可能还是清楚的，但对其他协作者来说，可读性会非常差。

更合理的方式通常是按“一个明确意图”提交。

## 提交信息是给后来的人看的

很多提交信息写成：

- `fix`
- `update`
- `修改一下`

这类信息当下可能图省事，但后面排查问题、查历史时几乎没有帮助。

好的提交信息不需要写成长文，但至少应该表达：

- 改了什么
- 为什么改

## 分支不要活得太久

一个功能分支拖得越久，后面越容易：

- 与主干偏离
- 冲突增多
- 难以 review
- 难以回滚

所以长期看，保持分支生命周期适中，比“一个大分支搞完整个版本”更稳。

## 冲突并不可怕，可怕的是不理解改动就解决

很多人处理冲突时，只想尽快让它过去，结果用的是“谁的代码看起来顺眼就保留谁”。

这在简单文件上可能没问题，但如果涉及逻辑变更，很容易把一部分正确改动无意中覆盖掉。

处理冲突时，还有一个更关键的问题是先理解两边各自改了什么。

## 前端项目尤其要注意产物文件

前端项目里常见一些自动生成内容，例如：

- 构建产物
- 锁文件
- 搜索索引
- 站点地图

这些文件是否应该进版本库，什么时候更新，团队最好有一致规则。否则很容易出现无意义冲突或脏提交。

## 写在最后

Git 协作真正决定效率的，往往不是命令熟不熟，而是团队有没有形成清晰的提交和分支习惯。

只要提交粒度更清楚、分支不要拖太久、冲突时先理解再解决，很多看起来麻烦的协作问题都会少很多。


前端团队协作中的 Git 习惯：很多低级问题其实和工具本身无关


前端开发早期，很多代码都是直接挂在全局作用域里的。

页面功能少的时候问题不明显，但随着项目变大，很快就会出现：

- 变量冲突
- 依赖关系混乱
- 文件加载顺序敏感
- 代码难拆难测

模块化正是为了解决这些问题而逐渐成为前端工程基础能力的。

## 模块化到底解决了什么

可以把模块化理解成：让代码有明确边界。

一个模块通常会说明：

- 它暴露什么
- 它依赖什么
- 它内部细节不希望外界直接碰什么

这样做的最大价值，不是语法更高级，而是系统更容易组织。

## 没有模块边界时会发生什么

如果所有变量和函数都散落在全局环境里，项目一大就很难管理。

常见问题包括：

- 同名函数被覆盖
- 某个文件必须先加载
- 调整一处代码影响未知区域

这些问题本质上都是边界缺失带来的。

## 模块化让依赖关系变得显式

以前一个函数能不能用，可能取决于某个文件是否先被引入；模块化之后，依赖可以直接通过导入关系表达出来。

这会带来很多工程收益：

- 更容易理解代码结构
- 更容易拆分文件
- 更容易做按需加载
- 更容易测试

## 模块拆分也不是越细越好

模块化的目标是清晰，不是把文件切得无限碎。

如果一个功能被拆成大量细小文件，但每个文件都彼此强依赖，阅读成本反而会上升。

所以模块拆分还有一个更关键的问题是按职责，而不是按行数。

## 模块边界会直接影响维护体验

一个边界清楚的模块，通常更容易做到：

- 只改局部
- 独立测试
- 替换实现
- 复用逻辑

反过来，如果模块之间相互穿透，虽然代码形式上用了 import/export，实际维护体验还是很差。

## 写在最后

JavaScript 模块化看起来像语法层能力，但它真正改变的是前端项目的组织方式。

随着项目越来越复杂，模块边界会越来越重要。理解模块化，不只是会写导入导出，而是开始学会让代码结构更清楚、更稳定、更容易协作。


JavaScript 模块化基础：为什么前端工程越来越离不开模块边界


我第一次真正对 Vite 上心，不是因为它是个新工具，而是因为我当时手上的一个 Vue 项目，开发体验已经被等待感拖得很明显了。

那个项目是典型的后台系统。页面不算特别花哨，但模块很多，表单、表格、弹窗、权限、图表、富文本都有。项目刚起的时候，Vue CLI 配 Webpack 跑得挺稳，谁也没觉得有什么问题。可越往后做，团队对开发环境的抱怨越多，而且大家抱怨的不是“不能用”，而是“总得等一下”。

启动要等。
切分支后重启要等。
改个样式保存要等。
偶尔热更新失效，再等。

这种等待单看都不算灾难，可它分散在一天里几十次操作中，最后会把人磨得很烦。尤其是做页面微调的时候，明明只是想看个字号或间距变化，却得不断在保存和刷新之间停顿。

## 我当时并不是真的想“换工具链”

说实话，2020 那会儿我对“再来一个新工具”没有特别强的热情。

因为从项目角度看，Webpack 并不差：

- 配置成熟
- 生态足够全
- Vue CLI 也很顺手

问题主要不在功能，而在开发过程里的反馈速度。

所以我最开始看 Vite，不是因为想追新，而是因为它正好踩在了那个痛点上。大家讨论它快，我就真的想知道，到底是“宣传里的快”，还是那种开发时一上手就能感受到的快。

## 第一次跑起来时，最直观的感受不是理念，而是轻

我还记得第一次拿一个小 Vue 页面试跑 Vite 的感觉。不是说配置多神奇，也不是说 API 多颠覆，而是那种很直接的轻快感一下子就出来了。

以前习惯了先启动一套 bundler，再等它把东西准备好。Vite 给人的第一反应则是：怎么这么快就起来了？

再改一个组件试一下，热更新的反馈也明显更利落。

这种体验不是靠 benchmark 才能说明的，它是开发者每天都能感知到的东西。尤其当你已经习惯“保存之后等一小会儿”这种节奏时，那种几乎立刻看到变化的感觉会很强。

## 后来我才慢慢理解，它打动人的不是“新”，而是它瞄准了一个长期被忽视的问题

很多前端工具都在强调能力完整、插件丰富、配置灵活。这些当然重要，但开发环境里的等待问题，过去经常被默认成“没办法，只能忍”。

Vite 让我第一次明显感觉到：这件事原来不是只能忍着。

它之所以会让很多 Vue 开发者迅速有反应，不是因为大家突然厌倦了 Webpack，而是因为我们都已经在真实项目里对那种启动慢、热更新钝的体验积累了足够多的不耐烦。

## 我没有马上迁项目，但我对工具链的判断开始变了

那次试完之后，我并没有立刻把手头的大项目迁过去。原因很现实：

- 旧项目的自定义配置很多
- 构建脚本和部署流程已经跑顺了
- 当时 Vite 还很新，不适合轻易全量切

但它还是改变了我对工具链的一些判断。

以前我更容易把开发工具看成“只要能跑就行”的基础设施。那次之后，我开始更认真地看待开发反馈本身。因为它并不是次要体验，而是每天都在影响写代码节奏的核心部分。

一个工具链如果让你每天多等几十次，每次只多几秒，最后吞掉的不是时间总量那么简单，还有注意力和耐心。

## 为什么 Vue 开发者会特别关注它

Vite 是 Evan You 发起的项目，这当然会天然吸引 Vue 社区的注意力。但我后来越来越觉得，真正让它被讨论起来的，不是“出身”，而是它刚好回应了 Vue 工程实践里一个持续存在的问题。

Vue 一直强调开发体验，这也是很多人喜欢它的原因。那当开发环境本身开始拖后腿时，大家自然会对一种更轻、更快的方案特别敏感。

换句话说，Vite 不是凭空冒出来的热点，它更像是对长期积累的不满给出的一个回答。

## 回头看，那次体验给我留下的感受其实很朴素

我现在再回想第一次接触 Vite，印象最深的不是它做了多少“革命性改变”，而是它让我重新感受到前端开发本来可以更顺。

很多工具发布时都会讲愿景、讲架构、讲趋势，这些都值得看。但真正让开发者决定继续用下去的，往往还是那种非常朴素的体验：

- 我改完代码能不能更快看到结果
- 我每天是不是少被打断一点
- 我是不是终于不用一直等

## 写在最后

Vite 在 2020 这个时间点最吸引我的地方，从来都不是“它很新”，而是它把开发过程里那种长期存在但经常被忽略的等待感，正面拿出来解决了。

它未必会立刻替掉所有工具链，但它至少让人意识到，开发环境的迟钝并不是只能接受的现实。对 Vue 开发者来说，这种感受很直接，也很难假装没发生过。


第一次用 Vite 跑 Vue 项目，最强烈的感受不是新，而是终于不用一直等


Vite 出来之后，Vue 开发者很自然会拿它和 Vue CLI 比。

这两者表面上都能帮你起一个项目、跑开发环境、做打包，但用起来的感觉并不一样。

## Vue CLI 的强项是成熟

Vue CLI 已经陪很多项目跑了很久。

它的优点很明确：

- 上手路径清楚
- Webpack 能力完整
- 插件和配置体系成熟

如果你在一个比较传统、稳定、历史包袱多的项目里，Vue CLI 仍然很靠谱。

## Vite 的吸引力在体验

Vite 最容易让人有感知的地方，就是开发阶段反馈更快。

你甚至不需要先把一堆原理吃透，光是启动和热更新速度，已经足够让人愿意试。

## 这不是淘汰关系

在 2020 这个时间点，更合理的理解不是“谁干掉谁”，而是：

- Vue CLI 代表成熟的 Webpack 工具链
- Vite 代表一种更轻、更快的新方向

## 写在最后

如果你现在手上项目跑得稳，没必要为了新就立刻重构全部工具链；但如果你正在起新项目，Vite 已经足够值得认真看一眼。

它带来的不是小修小补，而是开发体验上的一条新路。


Vue CLI 和 Vite 该怎么看：一个成熟稳，一个轻快直接


Vite 很快，这一点几乎不用太多证明。问题是，项目迁移从来都不只是“新工具更快，所以换过去”。

真正值得先想清楚的是：你现在的 Vue 项目依赖了多少旧工具链假设。

## 迁移前最该先看什么

通常至少要先盘一盘这几类东西：

- 自定义 Webpack 配置有多少
- 别名、环境变量、插件是否深度绑定
- 第三方 loader 是否很多
- 构建脚本和部署流程有没有耦合

如果这些东西很重，迁移就不只是换个启动命令。

## 快是收益，但不是全部收益

Vite 最明显的优势确实是开发快。

但迁移值不值得，最终还是看两件事：

- 迁移成本高不高
- 长期收益能不能覆盖这次改动

## 写在最后

Vue 项目迁到 Vite，最怕的不是踩坑，而是预期太轻。

如果把它看成一次工具升级，准备往往不够；如果把它看成工程假设切换，很多判断就会更稳。


把 Vue 项目迁到 Vite 之前，先想清楚你迁的是速度，还是整套工程假设


Vue 项目包一大，最容易出现的情况就是大家开始凭感觉优化。

有人觉得是图片大，有人怀疑某个 UI 库太重，也有人想先改构建参数。问题是，在没有看到真实体积分布之前，很多判断都只是猜。

这时最值得做的第一步，不是马上删代码，而是先把包看清楚。

## Bundle Analyzer 的价值不在图炫

很多人第一次看到打包分析图，会被那一堆彩色方块吸引。但真正重要的不是图好不好看，而是它让你知道体积到底花在了哪里。

例如：

- 哪个第三方库最重
- 哪些模块重复出现
- 哪个页面 chunk 明显偏大

这些问题如果不先搞清楚，后面的优化很容易瞎忙。

## Vue 项目里最常见的膨胀点

实际项目里包体积变大，常见原因通常包括：

- 引了过重的组件库
- 路由没有按需拆分
- 富文本或图表类库直接进了主包
- 工具库按整个包引入

这类问题很多并不是代码写错，而是结构没有控制住。

## 写在最后

Webpack Bundle Analyzer 最大的作用，是把“感觉有点大”变成“我知道大在哪里”。

前端优化最怕靠直觉。先把体积分布看清楚，再决定删什么、拆什么、延后加载什么，效率会高很多。


Vue 项目包太大时先别慌：Webpack Bundle Analyzer 到底能帮你看清什么


很多人第一次看到 Vue 的 `.vue` 文件时，都会觉得这东西很顺手。

模板、脚本、样式放在一个文件里，写组件时非常舒服。可写得顺手，不代表浏览器天生认识它。

浏览器并不理解 `.vue` 文件，能让这套写法成立的，背后其实是构建工具。

## 单文件组件为什么好用

单文件组件最大的好处，是把一个组件真正聚合在一起。

一个组件通常本来就包含三部分：

- 结构
- 逻辑
- 样式

以前这些内容可能散落在多个文件里，维护起来总要来回切。SFC 的好处就在于，组件边界更完整。

## 但浏览器并不会直接执行它

`.vue` 文件不是浏览器原生支持的格式，所以它必须先被处理。

这里 Webpack 的价值就体现出来了。它不是在“帮你写 Vue”，而是在帮你把这些开发阶段的写法转换成浏览器能运行的代码。

## vue-loader 的角色

如果说 Webpack 是总调度，那 `vue-loader` 就是专门处理 `.vue` 文件的那一层。

它会把：

- `<template>`
- `<script>`
- `<style>`

拆开处理，再交给对应的 loader 去接力。

这也是为什么你在 Vue 项目里明明只写了一个组件文件，最后浏览器却能正常拿到 JS 和 CSS。

## Webpack 不只是打包

很多初学者会把 Webpack 理解成“把文件合并一下”。实际上在 Vue 项目里，它做的事情远不止这些。

例如：

- 处理单文件组件
- 转换 ES Module
- 编译样式预处理器
- 处理图片和字体资源
- 做代码拆分

说到底，它在替你把开发体验和浏览器运行环境之间的差距补上。

## 写在最后

Vue 单文件组件之所以让人觉得自然，是因为 Webpack 把复杂度挡在了后面。

你写 `.vue` 文件时感受到的是组件化的轻松，但这份轻松本身，就是工具链替你换来的。理解这一点之后，再看 Vue 项目的构建过程就不会那么抽象了。


Vue 单文件组件为什么离不开 Webpack：从 .vue 文件说起


单页应用最容易被忽略的一个问题，就是“什么都先打进来”。

页面少的时候感觉不到，模块一多，首屏体积和初始化时间就会慢慢拉高。用户明明只访问了首页，却被迫把后台设置页、表单向导、图表模块一起下载了。

这就是代码分割存在的理由。

## 代码分割不是高级优化

很多人第一次接触 Webpack 的代码分割，会把它当成“后面再说的优化项”。可对 Vue 这种页面越来越多的单页应用来说，它其实很早就值得考虑。

因为只要页面结构明确、访问路径分层，自然就会想到：

- 首页不该加载后台页代码
- 列表页不该提前加载编辑器
- 低频弹窗没必要跟首屏一起进来

## Vue 路由懒加载就是最常见的切入点

在 Vue 项目里，代码分割最直接的入口通常就是路由级拆分。

```javascript
const UserList = () => import('./views/UserList.vue');
```

这行代码带来的不只是“写法更现代”，而是明确告诉打包器：这部分代码可以等真正访问时再加载。

## Webpack 帮你做的，不只是拆文件

如果没有打包器，你很难优雅地把应用切成多个按需加载的模块。

Webpack 在这里做的是：

- 找出依赖关系
- 生成独立 chunk
- 在运行时按需拉取

你写起来只是一行动态导入，真正复杂的事情都在背后。

## 别为了拆而拆

代码分割当然有好处，但也不是 chunk 越多越好。

拆得太碎，可能带来：

- 请求数变多
- 资源管理复杂
- 公共依赖重复加载判断更难

所以最自然的拆分单位通常还是页面、重模块和低频功能，而不是所有组件都切成一个单独 chunk。

## 写在最后

Webpack 的代码分割真正省下来的，不只是几百 KB 体积，而是用户第一次进入页面时不必要的等待。

Vue 应用做大之后，按需加载几乎不是“可选项”，而是结构设计的一部分。你越早理解这一点，后面的性能成本越低。


Vue 项目里的代码分割：Webpack 真正帮你省下了什么


项目目录一深，前端里最先变难看的往往不是业务逻辑，而是导入路径。

你会开始看到这种东西：

```javascript
import UserCard from '../../../../components/UserCard.vue';
```

第一次还能接受，文件一多以后，这种路径本身就会变成维护负担。

## 别名解决的不只是长度问题

很多人第一次配路径别名，会觉得它只是为了少写几个 `../`。这当然算好处，但更大的价值其实是稳定。

例如：

```javascript
import UserCard from '@/components/UserCard.vue';
```

这样写之后，组件位置一眼就清楚，也不会因为当前文件所在层级不同，导入路径长得天差地别。

## 目录结构调整时会省很多事

相对路径最麻烦的一点，是它过于依赖当前位置。

只要文件换个目录，很多引用都得跟着改。项目越大，这种成本越明显。

用了别名以后，路径更像是在描述“我依赖哪个模块”，而不是“我从这里往上跳几层再往下找”。

## 在 Vue 项目里尤其常见

Vue 项目里组件、视图、store、utils 很容易形成比较清晰的目录结构，这时候别名就特别顺手。

常见做法通常是：

- `@` 指向 `src`
- 或者再拆一些业务模块别名

这样导入语句本身会清爽很多。

## 写在最后

Webpack 路径别名看起来只是一个小配置，但它会持续改善项目的可读性。

工程化很多时候就体现在这种小地方：不是让代码显得更高级，而是让后面的人少看几眼就能明白文件关系。
