Qwik 中本地图片为什么推荐用 ESM 导入

2026-06-24
10604 分钟
...

在 Qwik 项目里,如果我们直接这样写本地图片:

<img src="/imgs/head.webp" alt="头像" />

代码本身是可以运行的,但 ESLint 可能会提示 qwik/jsx-img。这个提示不是错误,而是 Qwik 在提醒我们:本地图片可以通过 ESM 导入的方式进行优化

问题来源

Qwik 推荐把本地图片放到 src 目录下,然后通过 import 导入,并在路径后面加上 ?jsx

例如:

import ImgHead from '~/media/imgs/head.webp?jsx';

export default component$(() => {
  return <ImgHead alt="头像" />;
});

这样导入之后,图片会变成一个可以直接使用的组件。

为什么要这样做

直接写 <img src="/xxx.webp" /> 时,浏览器只会加载这一张原图。图片多大,用户就下载多大。

而使用 Qwik 的 ?jsx 导入后,Qwik 会在构建阶段处理图片,例如:

  • 自动压缩图片

  • 自动生成不同尺寸的图片

  • 自动生成 srcset

  • 自动补充 widthheight

  • 默认使用懒加载 loading="lazy"

  • 默认使用异步解码 decoding="async"

  • 文件名会带 hash,方便长期缓存

这些优化对博客、官网、移动端页面都挺有用,尤其是头像、封面图、文章配图这种经常出现在页面上的图片。

基本写法

普通写法:

import ImgHead from '~/media/imgs/head.webp?jsx';

export default component$(() => {
  return (
    <ImgHead
      alt="头像"
      class="h-24 w-24 rounded-full"
    />
  );
});

如果想指定图片尺寸,可以这样写:

import ImgHead from '~/media/imgs/head.webp?w=400&h=400&jsx';

注意:jsx 参数最好放在最后。

推荐:

import ImgHead from '~/media/imgs/head.webp?w=400&h=400&jsx';

不推荐:

import ImgHead from '~/media/imgs/head.webp?jsx&w=400&h=400';

public 目录和 src 目录的区别

如果图片放在 public 目录下,一般会这样访问:

<img src="/imgs/head.webp" alt="头像" />

这种方式简单直接,适合:

  • favicon

  • robots.txt 相关资源

  • 不需要优化的小图

  • 第三方脚本需要固定路径访问的资源

  • 一些背景图或静态下载资源

但它不会走 Qwik 的图片优化流程。

如果图片放在 src/mediasrc/assets 下面,就可以用:

import Image from '~/media/demo.webp?jsx';

这种方式适合:

  • 头像

  • 首页封面图

  • 博客文章配图

  • 产品图

  • 需要控制加载性能的图片

什么时候需要改

如果是页面里直接展示的图片,尤其是比较大的图片,建议改成 ?jsx 导入。

比如:

<img src="/imgs/about-bg.webp" alt="关于我背景" />

可以改成:

import AboutBg from '~/media/imgs/about-bg.webp?jsx';

<AboutBg alt="关于我背景" />

如果只是很小的图标,或者你本来就想保留固定路径,也可以不改。ESLint 提示只是性能建议,不是代码错误。

我的使用建议

在 Qwik 博客项目里,可以简单按这个规则处理:

图片类型推荐方式
头像?jsx 导入
首页大图?jsx 导入
文章封面?jsx 导入
普通文章插图?jsx 导入
faviconpublic
固定路径资源public
第三方 CDN 图片直接使用 URL
CSS 背景图视情况处理

总结

Qwik 的 qwik/jsx-img 提示,本质上是在提醒我们:本地图片不要只是当普通静态资源引用,也可以让构建工具帮我们做优化。

简单来说:

<img src="/imgs/head.webp" />

能用,但不会优化。

import ImgHead from '~/media/imgs/head.webp?jsx';

<ImgHead />

更适合 Qwik 项目,可以获得响应式图片、自动压缩、懒加载、宽高补全等优化。

所以在博客这种重视首屏速度和移动端体验的项目里,头像、封面、大图建议尽量使用 ?jsx 导入。

如果您觉得这篇文章有帮助,请点个赞吧~

分享文章

相关文章

更多文章 →
qwik2026-06-20
Qwik City 构建后 Godot 游戏 index.html 被删除的根因分析
背景 在 Qwik 博客项目中,我把 Godot Web 导出的游戏资源放在: Qwik 页面通过 iframe 嵌入游戏: 本地开发和本地静态资源检查时,游戏资源是存在的;但服务器执行完整构建后,发现: 消失了,最终导致 iframe 加载失败。 一开始容易误判为服务器部署脚本删文件、Git 没拉到资源、Godot 导出目录不对,或者 public 静态资源没有复制进 dist。但逐步排查后发现,根因不是这些。 现象复现 Qwik 项...
学习
qwik2026-02-28
理解 Qwik 的 routeLoader$:执行时机与 SSR/SSG/CSR 全景解析
🔑 一句话定义 是 Qwik City 专为“路由级数据加载”设计的声明式 API 。 它将数据获取逻辑与组件解耦,通过 序列化 + 状态恢复 实现“零 hydration”体验——这正是 Qwik “可恢复性”(Resumability)架构的灵魂所在。 📊 执行时机全景表(建议收藏!) | 场景 | 执行位置 | 触发时机 | 数据来源 | 客户端是否重执行? | | | | | | | | SSR | 服务端 | 用户请求页面...
学习
qwik2026-02-24
Qwik 技术深度回顾:从入门到实战
Qwik 是一个以 Resumability(可恢复性) 为核心的现代前端框架,它的目标是实现 O(1) 的 JavaScript 加载量,即无论应用多大,首屏加载的 JS 量都几乎为零。 本文将带你回顾项目中实际使用到的 Qwik 核心技术,帮助你快速重拾对 Qwik 的记忆。 1\. 核心概念: 后缀与懒加载 在 Qwik 中,你会发现大量的 API 以 结尾(如 , , )。 含义 : 标志着代码的 序列化边界 。编译器会将 包裹...
学习
qwik2026-02-24
Qwik博客性能优化实战
1\. 回归原生:用标准能力替代冗余脚本 曾几何时,为实现图片懒加载与资源预取,开发者常需手写复杂的 Intersection Observer 逻辑。但随着浏览器能力的演进,这类“黑科技”反而可能成为性能负担。 问题所在 : 自定义懒加载脚本不仅增加首屏 JS 体积,还会频繁触发 DOM 监听与计算,占用主线程资源,推高 Total Blocking Time(TBT)。 优化方案 : 图片加载 :直接采用 。浏览器内核级实现更高效、...
学习
qwik2026-01-15
Qwik 服务端能力深度解析
1\. Qwik 服务端架构概览 Qwik 采用独特的 可恢复性 (resumability)架构,使其服务端渲染(SSR)能力与传统框架有本质区别。在 Qwik 中,服务端不仅负责初始 HTML 生成,还负责: 组件序列化与反序列化 事件监听器的注册与恢复 数据流的管理(从服务端到客户端) 优化资源加载策略 Qwik 的服务端处理是 细粒度 的,允许开发者精确控制哪些代码在服务端执行,哪些在客户端执行,同时保持无缝协作。 2\. Qw...
学习
qwik2026-01-09
qwik api介绍
| 类别 | 名称 | 功能描述 | 适用场景 | | | | | | | 生命周期 | onMount | 组件挂载时执行 | 初始化DOM操作、设置事件监听 | | | onUnmount | 组件卸载时执行 | 清理资源、移除事件监听 | | | onVisible | 组件在视口可见时执行 | 懒加载内容、分析追踪 | | | onResume | 从序列化状态恢复时执行 | 恢复应用状态 | | 核心API | compone...
学习

评论

请登录后发表评论

去登录
加载评论中...

目录