react 组件可统一使用 .js 或 .jsx 扩展名，二者在功能上无本质区别；选择取决于项目规范、工具链配置及团队可维护性需求，现代构建工具（如 Vite、webpack、Next.js）默认均支持两者。
react 组件可统一使用 `.js` 或 `.jsx` 扩展名，二者在功能上无本质区别；选择取决于项目规范、工具链配置及团队可维护性需求，现代构建工具（如 vite、webpack、next.js）默认均支持两者。
在 React 开发实践中，关于组件文件应使用 .js 还是 .jsx 扩展名，常存在认知误区。事实上，这不是一个语法或运行时的强制要求，而是一个工程约定与工具链协同问题。
✅ 二者在技术上完全等价
只要构建工具（如 Babel、SWC、ESBuild）正确配置了 JSX 转换插件（例如 @babel/preset-react），无论是 .js 还是 .jsx 文件，都能被正常识别、解析并编译为合法 JavaScript：
// Button.jsx 或 Button.js —— 内容完全相同，均可正常工作 import React from 'react'; export default function Button({ children }) { return <button className="btn">{children}</button>; }现代主流工具链（Vite 3+、Create React App 5+、Next.js 13+、Webpack 5+）默认启用对 .js 文件中 JSX 语法的支持，无需额外配置。这意味着：你写 .js 文件里放
标签，不会报错；同理，.jsx 文件里写纯 JS 逻辑也完全合法。
? 为什么仍建议在组件文件中使用 .jsx？
尽管技术上无差别，但采用 .jsx 作为 React 组件的扩展名具有明确的语义化与工程优势：
- 清晰的职责标识：.jsx 明确传达“这是一个含 JSX 的 UI 组件”，便于快速区分容器逻辑（.js）、工具函数（.ts/.js）、样式模块（.module.css）等；
- ide 与编辑器增强：VS Code、webstorm 等工具会基于 .jsx 启用更精准的语法高亮、自动补全、PropTypes/typescript 类型推导及 ESLint 规则（如 react/react-in-jsx-scope）；
- 团队协作一致性：大型项目中，统一扩展名能降低新成员理解成本，避免“这个 utils.js 里怎么写了 ？”这类混淆；
- 未来兼容性准备：虽然目前无强制标准，但 React 官方文档、TypeScript 模板及 RFC 提案（如 Server Components）普遍采用 .jsx/.tsx，遵循社区惯例利于长期演进。
⚠️ 注意事项与最佳实践
- 避免混用：同一项目中不要部分组件用 .js、部分用 .jsx——这会破坏导入路径一致性（如 import Comp from ‘./Comp.jsx’ vs import Comp from ‘./Comp’），增加重构成本；
- TypeScript 用户请用 .tsx：若项目使用 TypeScript，组件必须使用 .tsx（而非 .ts），否则 JSX 语法将无法通过类型检查；
- 配置检查不可少：若坚持用 .js，请确认构建工具已启用 jsx: ‘react-jsx’（Babel）或 jsx: ‘preserve’（TSConfig），否则可能在 CI 环境或旧版工具链中意外失效；
- 服务端渲染（SSR）/边缘函数场景：某些轻量运行时（如 Cloudflare Workers + @swc/core）可能默认不处理 .js 中的 JSX，此时显式使用 .jsx 可规避潜在解析失败。
✅ 推荐方案（2024 主流实践）
| 场景 | 推荐扩展名 | 说明 |
|---|---|---|
| 新建 React 项目（Vite/Next.js/CRA） | .jsx（函数组件）、.tsx（TS 项目） | 语义清晰、工具友好、社区共识强 |
| 已有 .js 组件居多的存量项目 | 可暂不迁移，但新增组件统一用 .jsx | 平衡稳定性与渐进优化 |
| 纯逻辑工具库（无 JSX） | 始终用 .js 或 .ts | 避免误导，保持语义准确 |
归根结底，.js 与 .jsx 不是“对错”之分，而是“是否值得为可读性、可维护性与生态协同付出微小约定成本”的权衡。在几乎没有额外代价的前提下，选择 .jsx 是更专业、可持续的工程决策。