Vue 3中JSX的巧妙运用：从模板到渲染函数的进阶指南

1. 从“模板”到“代码”：为什么要在Vue 3里考虑JSX？

如果你是从React生态转过来的开发者，看到这个问题可能会觉得有点奇怪——JSX不是React的标配吗，怎么在Vue里还需要“巧妙运用”？而对于长期深耕Vue生态、习惯了.vue单文件组件（SFC）和模板语法的朋友来说，JSX可能更像一个“熟悉的陌生人”：知道Vue支持，但总觉得那是给“另一拨人”用的，或者只在渲染函数这种高级场景里偶尔露个脸。

我得说，这种想法在Vue 2时代或许成立，但在Vue 3的今天，是时候重新审视JSX了。Vue 3在底层设计上拥抱了更灵活的渲染机制，其响应式系统和组合式API（Composition API）的核心理念，与JSX这种声明式、基于JavaScript的UI描述方式，其实有着惊人的契合度。我并不是说SFC模板不好——它在绝大多数场景下依然是清晰、高效且Vue味十足的最佳选择。但当你遇到一些特定场景时，比如需要极致动态的渲染逻辑、复杂的条件分支嵌套、或者需要与TypeScript进行深度类型集成时，JSX能提供一种更“原生”的JavaScript编程体验。

简单来说，你可以把Vue的模板看作一门为UI定制的、声明式的领域特定语言（DSL），它优雅、简洁，但有其固定的语法边界。而JSX，则是JavaScript语法在UI描述上的一次扩展，它让你能在熟悉的JavaScript环境里，用if/else、map、reduce这些最基础的编程原语来构建视图。这种“什么都能写”的自由度，既是它的魅力，也是需要“巧妙运用”的原因——用不好就容易写出难以维护的“面条代码”。

所以，这篇文章不是一篇“非此即彼”的站队文，而是一份“工具使用指南”。我会结合具体的场景，聊聊在Vue 3项目中，哪些情况下JSX能成为你的秘密武器，以及如何规避它的常见陷阱，让它真正为你的开发效率和代码质量加分。

2. 环境搭建与基础心智模型转换

在开始写第一行JSX之前，我们得先把场子搭起来。这不仅仅是安装一个插件那么简单，更涉及到从“模板思维”到“JSX思维”的转换。

2.1 项目配置：让Vite认识JSX

现在Vue 3的新项目，十有八九是用Vite作为构建工具的。要让Vite支持Vue 3中的JSX（更准确地说，在Vue语境下常被称为TSX，当与TypeScript结合时），你需要安装官方的插件。

npm install @vitejs/plugin-vue-jsx -D # 或 yarn add @vitejs/plugin-vue-jsx -D # 或 pnpm add @vitejs/plugin-vue-jsx -D

然后，在你的vite.config.ts中引入并配置它：

// vite.config.ts import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' import vueJsx from '@vitejs/plugin-vue-jsx' export default defineConfig({ plugins: [ vue(), vueJsx(), // 放在vue插件之后 ], })

这个@vitejs/plugin-vue-jsx插件非常关键，它做了两件核心事：一是接管了.jsx和.tsx文件的编译，将它们转换为Vue能理解的渲染函数；二是注入了Vue JSX转换所需的运行时帮助函数。没有它，你的JSX语法在Vue项目里就是一堆无法识别的标记。

注意：如果你在配置后运行项目，遇到了类似error [err_module_not_found]: cannot find package 'vite' imported from的错误，这通常不是JSX插件的问题，而是你的项目根目录下可能缺少了node_modules，或者vite本身没有正确安装。请先确保执行了npm install安装了所有依赖。

配置好后，你就可以创建.jsx或.tsx后缀的文件了。我个人更推荐直接使用.tsx，即使你一开始不打算写复杂的类型，TypeScript也能为JSX提供更好的语法提示和错误检查。

2.2 核心语法差异：告别v-指令，拥抱JavaScript

这是思维转换的第一步，也是最重要的一步。在SFC模板中，我们通过v-if、v-for、v-on这些指令来告诉Vue“做什么”。而在JSX中，这些概念全部回归到最基础的JavaScript。

1. 条件渲染：v-ifvs&&和三元表达式在模板里你写：

<div v-if="isVisible">我会出现</div> <div v-else>否则我出现</div>

在JSX里，你直接写JavaScript：

const MyComponent = () => { return ( <div> {isVisible ? <div>我会出现</div> : <div>否则我出现</div>} {/* 或者更简单的逻辑 */} {isVisible && <div>只有为真时我才渲染</div>} </div> ) }

你会发现，逻辑变得更“内聚”了。条件判断就写在它控制的元素旁边，不需要在模板里跳来跳去找对应的v-else。

2. 列表渲染：v-forvsArray.map()模板写法：

<ul> <li v-for="item in list" :key="item.id">{{ item.name }}</li> </ul>

JSX写法：

const MyComponent = ({ list }) => { return ( <ul> {list.map(item => ( <li key={item.id}>{item.name}</li> ))} </ul> ) }

map是任何JavaScript开发者都熟悉的数组方法，用它来渲染列表非常自然。千万记得写key！这是Vue用来追踪节点身份的核心机制，在JSX里它就是一个普通的prop，但在列表渲染中不可或缺，否则可能导致诡异的渲染错误或性能问题。

3. 事件处理：v-onvsonXxx模板写法：

<button @click="handleClick">点击</button>

JSX写法：

const MyComponent = () => { const handleClick = (event) => { console.log('Clicked!', event) } return <button onClick={handleClick}>点击</button> }

事件监听器的属性名遵循驼峰命名法（onClick、onInput），其值直接传入一个函数引用。这里有一个重要的细节：在Vue模板中，@click="handleClick"会自动处理为handleClick($event)。而在JSX中，你传入的就是函数本身，事件对象会作为第一个参数自动传入。如果你需要传递额外参数，需要用一个箭头函数包裹：

<button onClick={(e) => handleClick(id, e)}>点击</button>

4. 动态属性与v-bind模板中绑定多个属性你可能用v-bind="object"。在JSX中，你可以直接使用ES6的扩展运算符，这简直是为JSX量身定做的：

const attrs = { id: 'my-id', class: 'container', 'data-test': 'button' } return <div {...attrs}>内容</div>

绑定单个属性则更简单，用花括号{}包裹JavaScript表达式即可：

return <div className={isActive ? 'active' : ''} style={{ color: textColor }}>内容</div>

注意，class在JSX中要写成className（与DOM API一致），style接受一个对象，而不是模板中的字符串。

2.3 定义组件：函数式与响应式

在JSX文件中，你定义组件的方式主要有两种，对应Vue 3的两种组件风格。

1. 函数式组件（推荐在简单场景使用）这更像React的函数组件，直接返回一个JSX元素。它没有内部状态（不使用ref,reactive），主要依靠props。

// Hello.tsx import { defineComponent } from 'vue' // 使用 defineComponent 可以获得更好的类型提示 export default defineComponent({ name: 'Hello', props: { msg: String }, setup(props) { // setup 函数，可以在这里处理逻辑 return () => ( // 注意：必须返回一个渲染函数 <div> <h1>{props.msg}</h1> </div> ) } })

或者使用更简洁的语法糖（需要Vue 3.3+）：

// 使用 `<script setup>` 风格的语法糖（在 .tsx 中） import { withDefaults, defineProps } from 'vue' interface Props { msg: string count?: number } // 定义props const props = withDefaults(defineProps<Props>(), { count: 0 }) // 直接编写渲染逻辑 const render = () => ( <div> <h1>{props.msg}</h1> <p>Count: {props.count}</p> </div> ) export default render // 导出渲染函数

2. 使用组合式API的响应式组件这是更强大和常用的方式，你可以在setup函数中使用ref,reactive,computed,watch等所有Vue响应式API。

import { defineComponent, ref, computed } from 'vue' export default defineComponent({ name: 'Counter', setup() { const count = ref(0) const double = computed(() => count.value * 2) const increment = () => { count.value++ } // 返回渲染函数，可以访问所有响应式状态和方法 return () => ( <div> <p>Count: {count.value}</p> <p>Double: {double.value}</p> <button onClick={increment}>+1</button> </div> ) } })

这里的关键点是：setup函数返回的是一个渲染函数，而不是直接返回JSX元素。这个渲染函数会在响应式数据变化时被自动调用。在函数内部，你可以像写普通JavaScript一样使用count.value来访问ref的值。

3. JSX的“杀手级”应用场景

了解了基础语法后，我们来看看JSX在哪些场景下能真正发挥出它的优势，让你觉得“这用模板写起来真别扭，还是JSX香”。

3.1 场景一：高度动态的渲染逻辑

这是JSX最核心的优势所在。当你的组件渲染结构需要根据复杂的数据结构或运行时状态动态生成时，JSX的威力就显现出来了。

假设你要渲染一个基于JSON配置的动态表单，配置可能长这样：

[ { "type": "input", "label": "姓名", "field": "name" }, { "type": "select", "label": "城市", "field": "city", "options": ["北京", "上海"] }, { "type": "checkbox", "label": "同意协议", "field": "agreement" } ]

在SFC模板中，你可能会写一堆v-if、v-else-if来判断type，或者用一个动态组件<component :is="...">。但用JSX，你可以写成一个非常清晰的渲染函数：

import { defineComponent } from 'vue' interface FieldConfig { type: 'input' | 'select' | 'checkbox' label: string field: string options?: string[] } export default defineComponent({ props: { config: { type: Array as PropType<FieldConfig[]>, required: true }, modelValue: { type: Object, required: true } }, emits: ['update:modelValue'], setup(props, { emit }) { const updateValue = (field: string, value: any) => { emit('update:modelValue', { ...props.modelValue, [field]: value }) } return () => ( <form> {props.config.map((item) => { // 根据类型动态渲染不同的表单控件 switch (item.type) { case 'input': return ( <div class="form-item" key={item.field}> <label>{item.label}</label> <input type="text" value={props.modelValue[item.field] || ''} onInput={(e) => updateValue(item.field, (e.target as HTMLInputElement).value)} /> </div> ) case 'select': return ( <div class="form-item" key={item.field}> <label>{item.label}</label> <select value={props.modelValue[item.field] || ''} onChange={(e) => updateValue(item.field, (e.target as HTMLSelectElement).value)} > <option value="">请选择</option> {item.options?.map(opt => ( <option value={opt} key={opt}>{opt}</option> ))} </select> </div> ) case 'checkbox': return ( <div class="form-item" key={item.field}> <label> <input type="checkbox" checked={!!props.modelValue[item.field]} onChange={(e) => updateValue(item.field, (e.target as HTMLInputElement).checked)} /> {item.label} </label> </div> ) default: return null } })} </form> ) } })

这段代码的清晰度在于，渲染逻辑和业务逻辑是内聚在一起的。switch语句的每个case直接返回对应的JSX元素，你可以很容易地看到每种配置类型对应什么样的UI。如果要新增一种type，比如'textarea'，你只需要添加一个case分支即可。在模板中实现同样的功能，要么需要定义多个子组件并用v-if切换，要么使用动态组件，但逻辑的连贯性会差一些。

3.2 场景二：作用域插槽（Scoped Slots）的灵活运用

作用域插槽是Vue一个非常强大的特性，它允许子组件向父组件的插槽内容传递数据。在模板中，它的语法是v-slot或#default。在JSX中，作用域插槽的写法更加“函数式”，理解起来也更直观。

子组件 (Child.jsx)：

import { defineComponent } from 'vue' export default defineComponent({ setup(props, { slots }) { const userData = { name: '张三', age: 25, city: '北京' } // 返回渲染函数 return () => { // 检查是否有默认插槽，并以函数形式调用它，传入数据 return ( <div class="child"> <h3>子组件区域</h3> {slots.default ? slots.default(userData) : <p>默认内容</p>} {/* 如果有命名插槽，也可以同样处理 */} {slots.footer && slots.footer({ timestamp: new Date().toISOString() })} </div> ) } } })

父组件中使用 (Parent.jsx)：

import { defineComponent } from 'vue' import Child from './Child.jsx' export default defineComponent({ setup() { return () => ( <div> <h2>父组件</h2> <Child> {/** 这里是一个函数，接收子组件传递过来的数据 */} {(slotProps: { name: string; age: number; city: string }) => ( <div> <p>来自子组件的数据：</p> <ul> <li>姓名：{slotProps.name}</li> <li>年龄：{slotProps.age}</li> <li>城市：{slotProps.city}</li> </ul> </div> )} {/** 命名插槽的写法，通过 `v-slots` 属性传递一个对象 */} {{ footer: (props: { timestamp: string }) => ( <div style={{ marginTop: '20px', fontSize: '0.8em' }}> 页脚 - 生成于：{new Date(props.timestamp).toLocaleString()} </div> ) }} </Child> </div> ) } })

在JSX中，作用域插槽就是一个返回JSX的函数。子组件通过slots.default(...)调用这个函数并传入数据，父组件则在子组件标签内部直接以函数的形式定义这个插槽内容。这种写法让数据流变得异常清晰：你一眼就能看出哪些数据是从子组件传上来的，父组件又是如何消费这些数据的。对于需要复杂数据交互的可复用组件（如表单封装、数据列表项渲染等），这种模式非常高效。

3.3 场景三：与TypeScript的深度集成

如果你使用TypeScript，那么JSX（TSX）带来的类型安全体验是模板难以比拟的。Vue 3本身对TypeScript支持极佳，结合TSX，你几乎可以在编写视图时获得全链路的类型提示和检查。

1. 组件Props的类型安全

import { defineComponent, PropType } from 'vue' interface User { id: number name: string email: string avatar?: string // 可选属性 } export default defineComponent({ name: 'UserCard', props: { // 使用 `PropType` 进行运行时类型声明，同时为TS提供类型 user: { type: Object as PropType<User>, required: true }, showEmail: { type: Boolean, default: false }, onSelect: { type: Function as PropType<(user: User) => void>, default: undefined } }, setup(props) { // 在这里，`props.user` 的类型是 `User` // `props.onSelect` 的类型是 `((user: User) => void) | undefined` const handleClick = () => { if (props.onSelect) { props.onSelect(props.user) // 类型安全，知道传入的是User对象 } } return () => ( <div class="user-card" onClick={handleClick}> {props.user.avatar && <img src={props.user.avatar} alt={props.user.name} />} <h4>{props.user.name}</h4> {props.showEmail && <p>{props.user.email}</p>} </div> ) } })

当你在其他组件中使用<UserCard>时，如果你的IDE支持TypeScript（如VSCode），你会得到完美的自动补全和类型错误提示。如果你传了一个不符合User接口的对象，或者漏掉了required的属性，在编写代码时就能立刻发现，而不是等到运行时。

2. 渲染函数的返回类型在setup返回的渲染函数中，TypeScript可以推断出你返回的JSX元素类型。虽然这通常不是问题，但在一些高级场景，比如编写高阶组件（HOC）时，明确的返回类型很有帮助。

3. 事件处理函数的参数类型在模板中，事件处理函数的参数类型往往需要你手动声明。而在TSX中，事件对象（如MouseEvent,KeyboardEvent）和自定义事件参数的类型可以清晰地定义和推断。

const handleInput = (e: Event) => { const target = e.target as HTMLInputElement console.log(target.value) // TypeScript知道target有value属性 } return <input onInput={handleInput} />

3.4 场景四：构建高阶组件（HOC）与渲染劫持

高阶组件在React中是一种常见的复用逻辑的模式。在Vue中，虽然组合式API和Composables是首选的逻辑复用方式，但有时你仍然需要创建一个组件，它包装另一个组件并增强其功能。JSX在这种模式下写起来非常顺手。

假设我们要创建一个withLoading高阶组件，它在数据加载时显示一个加载指示器：

// withLoading.tsx import { defineComponent, h, ComponentPublicInstance } from 'vue' // 这是一个函数，接收一个组件作为参数，返回一个新的增强组件 export function withLoading(WrappedComponent: any) { return defineComponent({ name: `WithLoading${WrappedComponent.name || ''}`, props: { loading: { type: Boolean, default: false }, // 其他原组件的props会通过 `...this.$props` 传递下去 }, setup(props, { slots, attrs }) { return () => { if (props.loading) { return <div class="loading-indicator">加载中...</div> } // 渲染被包装的组件，并传递所有的props、attrs和slots return h(WrappedComponent, { ...props, ...attrs }, slots) } } }) } // 使用示例：一个普通的展示组件 const UserProfile = defineComponent({ props: ['user'], setup(props) { return () => <div>用户名：{props.user?.name}</div> } }) // 增强后的组件 const UserProfileWithLoading = withLoading(UserProfile) // 在另一个组件中使用 export default defineComponent({ setup() { const user = ref(null) const loading = ref(true) onMounted(async () => { const data = await fetchUser() user.value = data loading.value = false }) return () => ( <div> <UserProfileWithLoading loading={loading.value} user={user.value} /> </div> ) } })

在这个例子中，withLoading函数接受一个组件，返回一个新的组件。新组件根据loadingprop决定是渲染加载状态还是渲染原组件。使用h函数（createElement的别名）来动态创建被包装组件的VNode。这种模式在JSX中非常自然，因为组件本身就是函数或对象，可以像普通值一样被传递和组合。

4. 避坑指南与性能优化

JSX给了你强大的灵活性，但“能力越大，责任越大”。如果不加注意，很容易掉进一些坑里，或者写出性能不佳的代码。

4.1 常见陷阱与解决方案

陷阱一：忘记setup返回渲染函数这是新手最容易犯的错误。在JSX组件中，setup函数必须返回一个函数（即渲染函数），而不是直接返回JSX或VNode。

// 错误！ setup() { const count = ref(0) return <div>{count.value}</div> // 直接返回了JSX，不会响应式更新 } // 正确！ setup() { const count = ref(0) return () => <div>{count.value}</div> // 返回一个函数 }

原因在于，Vue的响应式系统需要追踪依赖。当setup返回一个函数时，Vue会在响应式数据变化时重新执行这个函数，生成新的VNode。如果直接返回静态的VNode，数据变化了视图也不会更新。

陷阱二：在渲染函数中产生副作用渲染函数应该是纯函数，它只根据props和state计算并返回VNode。绝对不要在渲染函数内部执行如修改数据、发起网络请求、操作DOM等副作用。

// 错误！在渲染函数中修改响应式数据 return () => { count.value++ // 这会导致无限重新渲染！ return <div>{count.value}</div> } // 错误！在渲染函数中发起请求 return () => { fetchData() // 每次渲染都会发起请求，可能导致请求风暴 return <div>...</div> }

副作用应该放在setup函数的主体部分、生命周期钩子（onMounted,onUpdated等）或watch/watchEffect中。

陷阱三：不稳定的key在列表渲染时，key必须是稳定、唯一且可预测的。使用数组索引index作为key在列表项顺序会改变时（如排序、过滤、插入）是灾难性的，会导致Vue错误地复用DOM节点，引发状态错乱。

// 不佳：使用索引作为key {items.map((item, index) => ( <ListItem key={index} item={item} /> ))} // 推荐：使用数据中唯一且稳定的ID {items.map(item => ( <ListItem key={item.id} item={item} /> ))}

陷阱四：事件处理函数导致不必要的重新渲染在JSX中，如果你在渲染函数内部定义事件处理函数，每次重新渲染都会创建一个新的函数实例。对于子组件来说，这可能导致其不必要的重新渲染（因为props变了）。

const MyComponent = () => { const handleClick = () => { /* ... */ } // 每次渲染都创建新函数 return <Child onClick={handleClick} /> }

优化方案是使用useMemo（Vue中对应computed或useMemofrom@vueuse/core）缓存函数，或者将函数定义移到setup作用域外层（如果它不依赖响应式状态）。

import { ref, defineComponent } from 'vue' export default defineComponent({ setup() { const count = ref(0) // 将函数定义在setup作用域内，但依赖项变化时它不会变（除非你希望它变） const handleClick = () => { count.value++ } return () => ( <button onClick={handleClick}>点击了 {count.value} 次</button> ) } })

在这个例子中，handleClick在组件实例的生命周期内是稳定的，因为它被定义在setup函数内部，但闭包引用了count。每次渲染时返回的渲染函数中，onClick指向的都是同一个handleClick函数引用。

4.2 性能优化要点

1. 合理使用memo/shouldComponentUpdate在Vue 3中，你可以使用defineComponent的setup函数配合响应式系统的精细控制来避免不必要的子组件渲染。但对于函数式组件或简单组件，有时你希望明确告诉Vue：“只有当某些props变化时才重新渲染我”。你可以手动实现，或者使用第三方工具。

Vue 3本身没有直接的React.memo等价物，因为其响应式系统通常能自动优化。但你可以通过computed或watch来精确控制。一个常见的模式是，将可能频繁变化但子组件不关心的数据“提升”到父组件，或者使用v-memo指令（在模板中）。在JSX中，你需要更自觉地组织数据和组件结构。

2. 避免在JSX中内联复杂的对象或函数和内联事件处理函数类似，内联对象字面量也会导致每次渲染都创建新引用。

// 不佳：每次渲染都创建新的style对象 return <div style={{ color: 'red', fontSize: '14px' }}>内容</div> // 优化：将静态对象提取到组件外部或使用ref/computed const staticStyle = { color: 'red', fontSize: '14px' } // 或在setup中 const style = computed(() => ({ color: isActive.value ? 'red' : 'black', fontSize: '14px' }))

对于静态样式，提取为常量。对于动态样式，使用computed创建响应式引用。

3. 大型列表的虚拟滚动如果你需要渲染成百上千的列表项，直接使用map渲染所有DOM节点会严重影响性能。此时应该考虑虚拟滚动方案。在Vue生态中，你可以使用像vue-virtual-scroller这样的库。在JSX中集成虚拟滚动库通常也很直接，因为虚拟滚动组件本身就是一个接收渲染函数作为插槽的组件。

import { RecycleScroller } from 'vue-virtual-scroller' import 'vue-virtual-scroller/dist/vue-virtual-scroller.css' export default defineComponent({ setup() { const items = ref(/* 大型数组 */) return () => ( <RecycleScroller class="scroller" :items="items.value" :item-size="50" key-field="id" > {{ default: ({ item, index }) => ( <div class="item"> 第{index}项: {item.name} </div> ) }} </RecycleScroller> ) } })

4. 谨慎使用...扩展运算符传递props虽然{...props}很方便，但它会传递所有props，包括子组件可能不需要的。这可能导致不必要的属性被添加到DOM元素上（如果子组件是原生HTML元素），或者导致子组件进行不必要的props深度检查。尽量显式地传递需要的props。

5. 与SFC模板的混合使用与迁移策略

你不需要在全项目中二选一。Vue 3允许你在同一个项目中，甚至同一个应用中混合使用SFC（.vue）和JSX（.jsx/.tsx）组件。这为你提供了渐进式迁移和按需选型的灵活性。

5.1 混合使用

在SFC中使用JSX渲染函数在一个.vue文件中，你可以在<script setup>或setup函数中返回一个JSX渲染函数。

<!-- SFCWithJSX.vue --> <template> <!-- 这个template不会生效，因为setup返回了渲染函数 --> <div>这个不会显示</div> </template> <script setup lang="ts"> import { ref } from 'vue' const count = ref(0) // 在 <script setup> 中，以函数名 `render` 导出的函数会被用作渲染函数 const render = () => ( <div> <h1>我在SFC里用JSX！</h1> <button onClick={() => count.value++}>点了 {count.value} 次</button> </div> ) // 导出渲染函数 defineExpose({ render }) // 或者，如果你想这个组件只使用JSX渲染，可以直接导出render // export default render </script> <!-- 更常见的做法是，使用普通的script块 --> <script lang="ts"> import { defineComponent, ref } from 'vue' export default defineComponent({ setup() { const count = ref(0) return () => ( <div> <h1>我在SFC里用JSX！</h1> <button onClick={() => count.value++}>点了 {count.value} 次</button> </div> ) } }) </script>

在JSX中引用SFC组件这再简单不过了，就像引用任何其他Vue组件一样。

// JSXComponent.tsx import { defineComponent } from 'vue' import SfcComponent from './SfcComponent.vue' // 直接导入.vue文件 import AnotherJsxComponent from './AnotherJsxComponent' // 导入.jsx/.tsx文件 export default defineComponent({ setup() { return () => ( <div> <h2>JSX父组件</h2> {/* 像使用普通组件一样使用SFC组件 */} <SfcComponent someProp="hello" /> <AnotherJsxComponent /> </div> ) } })

构建工具（如Vite）会处理好这一切，.vue和.jsx文件都会被正确编译。

5.2 从SFC迁移到JSX的渐进策略

如果你有一个大型的现有Vue 2/3 SFC项目，想逐步尝试JSX，可以遵循以下策略：

1. 新组件用JSX：对于新开发的功能模块或独立组件，直接使用.tsx编写。这是风险最低的方式。
2. 复杂逻辑组件重构：找出项目中那些模板逻辑非常复杂（嵌套了很多v-if、v-for、v-slot）的组件，将其重构成JSX组件。这往往能显著提升代码可读性。
3. 在SFC内局部使用：对于一个现有SFC，如果其中某一部分的渲染逻辑特别动态，可以先将这部分逻辑提取到一个独立的JSX渲染函数中，在SFC的setup里使用。这相当于一次局部的重构。
4. 工具函数与渲染逻辑分离：JSX鼓励将渲染逻辑视为纯函数。你可以先将组件中复杂的计算属性或方法，重构为纯JavaScript函数，放在单独的工具文件中。这为后续将模板改为JSX打下了基础。

5.3 选择何时使用JSX：一个简单的决策树

面对一个组件，如何决定用SFC还是JSX？你可以问自己以下几个问题：

• 渲染逻辑是否高度动态，依赖复杂的JavaScript表达式？如果是，JSX可能更清晰。
• 是否需要与TypeScript实现极致的类型安全集成（尤其是组件Prop和事件）？如果是，TSX体验更好。
• 组件是否主要作为渲染封装，逻辑简单，UI结构稳定？如果是，SFC模板更简洁直观。
• 团队熟悉度如何？如果团队主要成员来自React背景，或者对JavaScript更熟悉，JSX上手更快。如果是纯Vue背景，SFC模板心智负担更小。
• 是否需要构建高阶组件（HOC）或使用渲染函数模式进行高级抽象？如果是，JSX更自然。

没有银弹。在我的实践中，我倾向于将JSX用于“逻辑密集型”组件（如表单生成器、动态表格、可视化图表封装），而将SFC用于“展示密集型”组件（如布局容器、静态页面、简单的UI控件）。这种混合模式能最大化两种技术的优势。

6. 生态工具与周边支持

使用JSX开发，除了Vue核心，周边的工具链支持也很重要。

TypeScript配置在你的tsconfig.json中，确保启用了JSX相关配置：

{ "compilerOptions": { "jsx": "preserve", // Vue JSX插件会处理转换，所以让TS保留JSX语法 "jsxImportSource": "vue", // 告诉TS JSX工厂函数来自Vue (Vue 3.3+) // 或者对于旧版本，可以使用： // "jsx": "preserve", // "jsxFactory": "h", // "jsxFragmentFactory": "Fragment" } }

"jsx": "preserve"告诉TypeScript不要编译JSX，留给Vite/Webpack的Vue插件处理。"jsxImportSource": "vue"是Vue 3.3+引入的，用于更好的类型支持。

IDE支持（VSCode）

1. Volar：这是目前Vue开发的官方推荐语言工具。它对.vue和.jsx/.tsx都提供了绝佳的支持，包括语法高亮、类型提示、自动补全、跳转到定义等。确保禁用旧的Vetur插件。
2. TypeScript Vue Plugin (Volar)：安装Volar时，通常会同时安装这个插件，它专门用于在.ts/.tsx文件中提供Vue相关的智能提示。
3. ESLint & Prettier：配置ESLint规则集（如@vue/eslint-config-typescript）和Prettier来保持代码风格统一。Prettier有专门的Vue/JSX格式化规则。

测试使用@vue/test-utils测试JSX组件与测试SFC组件没有本质区别。你仍然可以使用mount或shallowMount。因为JSX组件最终编译成渲染函数，测试工具对待它们的方式是一样的。

import { mount } from '@vue/test-utils' import MyJsxComponent from './MyJsxComponent' test('renders correctly', () => { const wrapper = mount(MyJsxComponent, { props: { msg: 'Hello' } }) expect(wrapper.text()).toContain('Hello') })

SSR (Nuxt.js)如果你使用Nuxt.js进行服务端渲染，从Nuxt 3开始，其对Vue 3和JSX的支持是开箱即用的。你可以在Nuxt项目的components/目录下直接放置.tsx文件，它们会被自动识别和导入。Nuxt的构建层基于Vite，同样会使用@vitejs/plugin-vue-jsx插件。

7. 总结与个人实践心得

回过头看，在Vue 3中“巧妙”运用JSX，其精髓不在于追求语法的新奇，而在于选择正确的工具解决正确的问题。JSX不是用来替代SFC模板的，它是模板能力的一个强大补充，尤其在处理渲染逻辑与JavaScript代码深度耦合的场景时，它能提供更直观、更类型安全、更富表达力的开发体验。

从我个人的项目经验来看，有几点体会特别深刻：

第一，从“声明式”到“命令式”的思维转变需要适应期。刚开始写JSX时，总会不自觉地想去寻找对应的v-指令。但一旦你习惯了用&&、三元表达式和map来表达条件与循环，你会发现这种“一切皆JavaScript”的自由度能让你更流畅地实现复杂的交互逻辑。特别是当你需要根据一个复杂对象的状态来动态决定渲染数十种不同的UI变体时，一个清晰的switch语句或一系列if-return语句，远比在模板里嵌套多个<template v-if>要容易维护得多。

第二，TypeScript与JSX的结合是“王炸”。这可能是促使我越来越多地使用TSX的最大动力。在组件契约（Props、Emits、Slots）上获得的类型安全，极大地减少了组件间协作的bug。当你重构一个组件，修改了某个Prop的类型，所有使用它的父组件都会立刻在IDE里报错，而不是等到运行时才崩溃。这种开发体验的提升是实实在在的。

第三，警惕“过度灵活”导致的混乱。JSX的灵活性是一把双刃剑。我曾经在一个早期项目中，因为过度使用内联函数和复杂的逻辑表达式，导致某个组件的渲染函数变成了一个长达300行的“巨无霸”，难以理解和调试。后来我定下了一个简单的规则：如果渲染函数的主体逻辑超过了50行，或者嵌套层级超过3层，就必须考虑拆分子组件、提取工具函数或使用计算属性。保持每个渲染函数的简洁和单一职责，是维持JSX代码可维护性的关键。

第四，混合技术栈并不可怕，但需要约定。在一个项目中同时存在.vue和.tsx文件，只要团队有明确的约定（比如“业务页面用SFC，通用底层UI组件库用TSX”），并不会造成混乱。反而，这种按需选型的能力让团队可以更灵活地应对不同的需求。Vue 3的架构很好地支持了这种混合模式。

最后，我的建议是：不要因为JSX“很酷”就去用它，也不要因为习惯了模板而排斥它。下次当你面对一个渲染逻辑特别棘手、模板写起来感觉别扭的组件时，不妨新建一个.tsx文件试试。从一个小组件开始，体验一下在JavaScript的海洋里畅快编写UI的感觉。你可能会惊喜地发现，它为你打开了另一扇窗。