parcel 默认自动处理 css：识别 html 的 link 或 js 的 import，执行语法检查、@import 内联、url 路径重写、压缩（生产）及自动加前缀；不支持 cssnext 新特性，需手动装插件。
Parcel 默认如何处理 .css 文件
Parcel 会自动识别入口 HTML 中的 <link rel="stylesheet">，或 JS 中的 import './style.css'，并启用内置 CSS 处理流程——不需要配置文件、不需要插件声明。
它默认执行：语法检查（PostCSS）、@import 内联、url() 路径重写、CSS 压缩（生产环境），以及自动添加浏览器前缀（通过内置的 PostCSS preset）。
- 不支持
cssnext或postcss-preset-env的新特性（如:has()、color-mix()），除非手动装插件 -
url('./img.png')会被转为哈希路径并拷贝到输出目录；但url('https://...')或url(data:...)不动 - 如果 CSS 文件里有
@import 'normalize.css'，Parcel 会尝试解析 npm 包，但仅限于已安装且导出 CSS 的包（比如normalize.css可以，lodash不行）
为什么 import 一个 CSS 文件有时没效果
常见现象是：JS 中写了 import './index.css'，但页面没应用样式。根本原因不是 Parcel 没打包，而是它不会自动把 CSS 插入 DOM —— 它只生成 CSS 文件或内联字符串，插入行为得你来控制。
- 在浏览器环境，默认输出的是单独的
bundle.css，靠 HTML 中的<link>加载；JS 里的import仅触发构建依赖，不等于“执行注入” - 如果用
parcel build，CSS 会被提取为文件；但用parcel serve时，开发服务器会通过 HMR 注入 style 标签 —— 所以热更新看着正常，构建后却消失 - 想让 JS 主动注入，得用
import * as cssText from './index.css?inline'，然后手动创建<style></style>标签（?inline是 Parcel 的特殊查询参数）
postcss.config.js 不生效的典型原因
Parcel v2+ 会读取项目根目录下的 postcss.config.js，但有几个硬性前提：配置文件必须导出对象（不能是函数），且不能依赖未安装的插件。
立即学习“前端免费学习笔记（深入）”；
- 若配置中写了
plugins: ['postcss-nested']，但没运行npm install postcss-nested，Parcel 会静默跳过该插件，不报错也不警告 - Parcel 自带的 autoprefixer 版本较旧（v10.4.x），如果你在 config 里显式写了
autoprefixer: { overrideBrowserslist: [...] }，它才按你的规则跑；否则仍用内置默认列表（defaults） - 配置文件里写
module.exports = () => ({ plugins: [...] })（返回函数）—— Parcel 直接忽略，因为只接受同步对象导出
用 parcel build 输出 CSS 时的路径陷阱
输出的 CSS 文件中，所有 url() 会被重写为相对于最终 CSS 文件的位置，而不是源文件位置。这个“相对基准”由 --public-url 和输出目录结构共同决定。
- 默认
--public-url ./，意味着dist/bundle.css里的url(img/icon.png)会请求dist/img/icon.png；但如果实际图片被 Parcel 放到了dist/assets/icon-abc123.png，就 404 - 不要手动在 CSS 里写
url(../assets/...)，Parcel 不会做向上解析修正；它只按原始路径找文件，再根据输出结构重映射 - 想控制资源输出路径，应改用
alias配置或在package.json中加"targets": { "default": { "publicUrl": "/static/" } }
最易被忽略的一点：Parcel 对 CSS 的处理是“单次静态分析”，不执行 CSSOM，也不模拟运行时路径计算。所以所有路径逻辑必须在构建前就确定好，没法靠 JS 动态 patch。
