@import在小程序中必须顶格写于文件首行,仅支持相对路径,不支持绝对路径、包路径、嵌套引入及bom/空格,否则静默失效;应由app.wxss统一引入公共样式以避免重复和冲突。

@import 在小程序中不能当 CSS 的 <link> 用,它不支持绝对路径、包路径、嵌套引入,也不认 BOM 或首行空格——写错一行,样式就静默失效,连报错都没有。
为什么 @import 写了却没生效
常见现象是:改完 @import 后页面样式没变,开发者工具里也查不到错误,控制台无提示,网络面板里也看不到请求——因为编译器压根没加载那个文件。
-
@import必须严格顶格写在文件第一行,前面不能有任何字符(包括 UTF-8 BOM、空格、制表符、注释) - 路径必须是相对路径,且以当前文件为基准;写成
@import '/common/base.wxss'或@import 'node_modules/weui-miniprogram/xxx.wxss'都会静默失败 - 路径里的
..层数要数准:比如页面在pages/detail/detail.wxss,要引入common/utils.wxss,就得写@import '../../common/utils.wxss'; - 末尾分号
;不能省,漏了也会跳过整行
如何安全地在 app.wxss 中引入公共样式
最稳的方式是把所有复用样式集中到一个地方,由 app.wxss 统一导入,避免页面级重复引入导致权重冲突或解析开销。
- 把公共样式文件(如
common/base.wxss、common/icon.wxss)放在与app.wxss同级的common/目录下 - 在
app.wxss顶部直接写:@import 'common/base.wxss';(注意没有../,因为app.wxss在根目录) - 如果用了第三方库(如 weui),构建 npm 后路径通常是
miniprogram_npm/weui-miniprogram/weui-wxss/dist/style/weui.wxss,必须确认该路径真实存在于项目中,再写进app.wxss - 不要在多个页面 wxss 里各自
@import同一份文件,否则样式会重复注入,可能因选择器权重或层叠顺序引发意料外覆盖
为什么不能链式 @import(A 引入 B,B 引入 C)
小程序 WXSS 编译器只解析第一层 @import,第二层及以后的语句被完全忽略——这不是兼容性问题,是设计限制。
- 比如
A.wxss里@import 'B.wxss';,而B.wxss里写了@import 'C.wxss';,那么C.wxss的内容不会进入最终样式表 - 解决方案只有两个:要么把
C.wxss的内容手动合并进B.wxss,要么让A.wxss同时@importB.wxss和C.wxss - 更推荐扁平化:把主题色、工具类、动画等拆出的子文件,全部由
app.wxss一次性引入,不依赖中间层
引入字体图标或第三方 wxss 的典型陷阱
很多人卡在字体图标(如 iconfont、Font Awesome)或 weui 上,根本原因不是路径写错,而是忽略了构建和引用层级的耦合关系。
- 下载的
iconfont.css必须手动重命名为iconfont.wxss,否则不识别 - weui 的
@import路径依赖 npm 构建结果,必须先执行「构建 npm」,再检查miniprogram_npm/下是否存在对应文件,最后才写入app.wxss - 引入后若图标不显示,优先检查 wxml 中 class 名是否拼写正确(如
fa fa-star)、是否漏了font-family声明,而不是怀疑@import失效 - 所有通过
@import加载的样式,都遵循 CSS 层叠规则:页面 wxss > app.wxss > 公共 wxss;但若选择器权重相同,就近原则生效,这点容易被忽略
真正麻烦的从来不是“怎么写”,而是“为什么写了没反应”——小程序的 @import 没有容错机制,它不报错,只沉默跳过。所以每次加完,务必打开开发者工具的「调试器 → 样式」面板,确认目标样式规则是否真的出现在计算样式里。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











