2026全栈选型：SpringBoot3+Vue3+TypeScript实践与避坑指南

2026年如果你还在斟酌全栈技术栈的选型，我直接说结论：SpringBoot3依然会是Java后端圈子里无可争议的主力框架，Vue3经过这几年的沉淀已经完成了整个生态的收口，TypeScript则从“前端工具”升级成了整个前端工程化的底层语言。把这套组合拼在一起，并不是单纯追新，而是三者在各自的领域都代表了当前最稳妥、最成熟、也最不缺人接手的路线。

这篇内容我会从三套技术各自的选型逻辑讲起，再拆到安全认证、类型共享、工程搭建、高频避坑这些实操层面，尽量贴合实际项目中真正会遇到的问题，而不是只摆概念。适合正在从SpringBoot2往3迁移的后端同学、准备从Vue2或JS跳到Vue3+TS的前端同学，以及想系统搭一套前后端分离全栈项目的初级工程师，看完可以直接照着动手。

1. 为什么2026年全栈标杆是SpringBoot3+Vue3+TypeScript

1.1 后端踩过SpringBoot2的坑，才懂SpringBoot3的好

过去几年Java后端最常见的组合是SpringBoot2.x加JDK8，这套搭配确实稳定，但稳定也意味着保守。SpringBoot3把基线直接抬到了JDK17，很多人一开始是抗拒的，觉得“升级JDK又不会带来业务价值”。可真当接手几个存量项目后你会发现，JDK8时代的痛点越来越明显：字符串处理和集合操作的代码啰嗦、空指针问题靠肉眼排查、虚拟线程更是完全没得用。

SpringBoot3真正让我觉得“回不去”的点有三个。第一是Jakarta EE命名空间全面替换javax，虽然迁移时改import很烦，但一次性把历史包袱卸干净了；第二是Spring Security 6的配置方式大改，SecurityFilterChain的Bean式写法比原来继承WebSecurityConfigurerAdapter清晰得多；第三是Spring Boot 3.2之后对Java 21虚拟线程的原生支持，一个开关就能让高并发IO密集型服务的吞吐量上一个大台阶。

到了2026年，SpringBoot3.x已经是事实上的默认选项，新项目几乎不会有人再从SpringBoot2起步。而且SpringBoot3.4之后RestClient、HTTP Interface这些新特性逐步成熟，写服务间调用、写REST客户端都比以前舒服太多。如果你还在用SpringBoot2，不是不能跑，而是整个生态的新组件、新教程、新解决方案都在往3.x靠，继续守旧只会让学习成本和维护成本越来越高。

1.2 Vue3用两年磨完了生态，今年是上手的最佳时机

前端框架的竞争这几年一直没停过，React有庞大的社区，Vue走的是渐进式上手路线。但Vue3刚发布那阵子其实挺尴尬：Composition API是个新概念，Element Plus、Vant等配套组件库还在适配期，很多团队评估完还是选择继续用Vue2。到了2026年，情况完全反过来了，Vue2已经进入维护尾声，生态里的主流库几乎全部完成了对Vue3的兼容，Vite更是把构建体验拉到了秒级。

Vue3的Composition API一开始被吐槽“把简单的事情搞复杂了”，实际用下来你会发现它解决的恰恰是Vue2最大的痛点——代码复用。Vue2时代做逻辑复用靠mixin，但mixin有隐式依赖、命名冲突、来源不清晰的问题，复杂项目里根本不敢用。Composition API把逻辑按功能组织成组合式函数，相当于把“复制粘贴一段data和method”变成了“直接调用一个函数”，代码的阅读成本低了非常多。

再加上Vue3的响应式系统整体重写，用Proxy替代了Object.defineProperty，数组和对象属性的增删不再丢响应性，性能也比Vue2强。TypeScript方面，Vue3的源码本身就是用TS写的，对类型推导的支持是天然友好的，配合defineProps、defineEmits、defineModel这些编译宏，写组件时的类型体验已经接近Angular那种“自带类型”的框架。影视级“快到起飞”可能有点夸张，但开发体验的提升是真的能感知到的。

1.3 类型安全：全栈开发最容易被忽视的协作成本

前后端分离开发，最烦的不是写接口，而是对接口。后端定义了一个字段叫userId，前端拿到的可能是user_id，这种不一致问题在纯JS项目里只能靠人肉review。TypeScript的出现把“变量有类型”这件事变成了前端工程的默认约束，但真正让TS发挥全栈价值的，是前后端共享类型的那套做法，后面会详细展开。

在团队协作层面，TypeScript最大的意义不是让前端代码不出错，而是让接口文档变成可执行的东西。后端把OpenAPI描述文件生成出来，前端直接基于它生成TS类型，字段对不上在编译期就暴露了，而不是等到联调时找半天。这种“类型即契约”的协作模式，在2026年已经有很成熟的工具链，比如springdoc-openapi配合openapi-typescript，几乎零成本接入。

更深一层，TypeScript还改变了前端的工程化方式。从tsconfig的严格模式，到eslint-plugin-vue配合typescript-eslint，再到vue-tsc做类型检查，TypeScript已经渗透到了代码检查、构建、测试、发布的所有环节。2026年再招前端，如果简历里只写“熟悉JavaScript”没有TS经验，很可能直接被筛掉。对于想转全栈的后端同学来说，先掌握TypeScript再接触前端框架，学习曲线会比直接啃JS流畅得多。

2. 后端核心：SpringBoot3从启动到安全认证的关键迁移

2.1 JDK17基线：为什么必须从JDK8迈出这一步

SpringBoot3的最低要求是JDK17，这意味着你不能再拿着JDK8去跑新项目了。JDK17是长期支持版本，免费商用，Oracle和OpenJDK的发行版都很成熟，2026年用JDK17甚至JDK21都是很稳妥的选择。很多团队卡在升级这一步，主要是历史项目里有大量依赖旧版javax的第三方库，以及一些基于反射和字节码操作的老框架在Jakarta命名空间下会出兼容问题。

但如果你是从零搭新项目，完全没有历史包袱，我建议直接上JDK21。JDK21引入了虚拟线程，配合SpringBoot3.2之后的配置，只需要设置spring.threads.virtual.enabled=true就能让Tomcat处理请求时使用虚拟线程。我实测过一个简单的模拟IO场景，同样配置下虚拟线程模式比平台线程模式的吞吐量能提升好几倍，代码几乎不用改，这种性价比非常值得。

迁移过程中最常见的坑是第三方依赖的版本兼容。比如MyBatis-Plus需要3.5.3以上版本才支持SpringBoot3，一些操作Excel、生成PDF的老库可能还没有更新到jakarta命名空间。我建议新项目尽量选用已经明确支持SpringBoot3的库，碰到不兼容的旧库不要硬适配，换替代方案往往更省时间。算是给所有升级到SpringBoot3的团队一个忠告：依赖清单一定要先捋清楚再动手写代码。

2.2 Security 6和OAuth2：配置方式真的变了

Spring Security 6是SpringBoot3默认的版本，最直观的变化是WebSecurityConfigurerAdapter被彻底移除，改成基于SecurityFilterChain和SecurityConfigurer的Bean注册写法。早期资料里常见的继承WebSecurityConfigurerAdapter、重写configure(HttpSecurity http)那套已经过时了，现在更推荐用Lambda DSL风格：

@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/**", "/public/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated() ) .csrf(csrf -> csrf.disable()) .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .oauth2ResourceServer(oauth2 -> oauth2 .jwt(jwt -> jwt.decoder(jwtDecoder()))); return http.build(); }

这种写法把每个配置项都放进一个独立Lambda里，读起来更直观，也不容易出现方法链断掉的情况。OAuth2方面，SpringBoot3对授权服务器和资源服务器做了更清晰的分层，你可以在同一个项目里同时配置授权码模式和client credentials模式。对于常见的“前端登录拿token、后端鉴权用token”场景，可以基于Spring Security 6加一个简单的OAuth2认证服务器，也可以用现成的授权服务配合JWT做无状态鉴权。

实际项目里最容易被忽略的是JWT的密钥管理和刷新策略。不要硬编码密钥在代码里，建议用环境变量或配置中心管理。JWT的有效期也别设太长，我个人习惯是access token设30分钟，refresh token设7天，前端拦截到401后自动用refresh token换新的access token，这样用户体验和安全性都能兼顾。

2.3 部署形态升级：原生镜像与虚拟线程带来的变化

SpringBoot3的另一大变化是官方支持GraalVM原生镜像，通过Spring Native或Spring Boot官方提供的AOT（Ahead-Of-Time）编译，可以把应用打包成原生可执行文件。原生镜像启动速度快到几十毫秒级别，内存占用也大幅降低，非常适合容器化和Serverless部署。但代价是编译时间长、反射配置繁琐，一些依赖动态代理的框架需要用额外配置来适配。

我自己的经验是，中小型项目别轻易上原生镜像，除非你对GraalVM的坑非常熟悉。运行时反射、CGLIB代理、资源文件访问这些问题在原生镜像下都可能变成雷区，排查起来比启动慢几秒痛苦得多。2026年更务实的做法是先跑在JVM上，启动慢一点无所谓，稳定和可维护才是第一位；等业务规模到了一定程度，再评估哪些模块值得AOT编译。

部署层面需要注意的还有CDS（Class Data Sharing）和虚拟线程的搭配。CDS能减少JVM启动时的类加载开销，配合SpringBoot3的AOT生成提示文件，能让容器场景下的启动速度提升不少。如果你用Docker部署，尽量用分层构建把依赖层和应用层分开，这样每次代码更新只需要重建最后一层，镜像仓库的传输量会小很多。

3. 前端主力：Vue3组合式API与TypeScript的融合实践

3.1 组合式API对代码组织的真实重塑

Vue2时代写组件，data、computed、methods、watch分别放在不同区块里，组件文件一旦超过300行，想追踪一个业务功能的完整逻辑就得上下翻好几遍。Composition API把同属一个业务逻辑的代码聚集到一起，是把组织方式从“按类型”变成了“按功能”。举个最简单的例子：一个用户列表页需要拉取用户、处理筛选、控制分页，以前这些状态分散在data和methods中，现在可以专门写一个useUserList函数：

export function useUserList(api: UserApi) { const list = ref([]); const loading = ref(false); const keyword = ref(''); const fetchList = async () => { loading.value = true; try { list.value = await api.getUsers({ keyword: keyword.value }); } finally { loading.value = false; } }; watch(keyword, () => { fetchList(); }); return { list, loading, keyword, fetchList }; }

这段逻辑可以被任意组件复用，组件里只要调用useUserList就能拿到列表状态和方法，不需要mixin，不需要事件总线。一开始写Composition API会觉得“很散”，因为状态和方法都变成变量了，但配合setup语法糖之后，代码的组织感会越来越舒服。

需要留意的是，Composition API不等于自由发挥。团队里还是应该有统一的规范，比如组合式函数统一以use开头放src/composables目录，副作用逻辑（定时器、事件监听）必须在onUnmounted里清理。没有规范，Composition API很容易变成一盘散沙，反而比Options API更难看。

3.2 响应式原理与diff算法面试必考点

Vue3的响应式系统基于Proxy实现，和Vue2的Object.defineProperty相比，最大的区别是能拦截整个对象的所有属性操作，包括新增属性、删除属性、通过索引访问数组元素。这意味着你不再需要Vue.set或者$forceUpdate这种补偿手段，响应式行为更符合直觉。

但Proxy也不是没有代价。它对对象的每一次读取和写入都走拦截器，嵌套对象需要层层递归代理，在特别巨大的响应式对象上会有一定的性能损耗。实际开发中要注意避免把大量非响应式数据放进reactive里，比如一次性拉取的静态字典数据，用普通变量或shallowRef处理会更合适。

diff算法方面，Vue3的patchKeyedChildren做了不少优化。在对比新旧子节点列表时，会先从头开始同步，再从尾部开始同步，然后对中间未知序列做处理，通过最长递增子序列算法来最小化移动次数。这个改进让列表更新时的DOM操作更少，特别是在做大表格渲染、树形组件这类场景时能感受到差别。如果你正在准备vue3面试题，把diff过程结合key的作用一起讲，会比单纯背源码结论更有说服力。

3.3 从Webpack到Vite的工程化体验跃迁

Vite是基于ESModule的构建工具，开发环境启动不打包，直接按需编译浏览器请求的文件，所以大型项目也能做到毫秒级热更新。2026年用Vite创建Vue3项目已经是默认选项，用npm create vue或npm create vite命令就能拉一套带Vue3+TS+Router+Pinia的完整工程模板。

Vite做生产构建时用Rollup打包，虽然极端复杂场景下的代码分割配置比Webpack稍微麻烦一点，但日常项目完全够用。组件库按需引入方面，比如Element Plus的unplugin-vue-components配合unplugin-auto-import，安装之后写组件时自动导入样式和API，不需要手动按需加载，体验比之前好了很多。

从Webpack迁移过来的团队最不适应的可能是vite.config.ts里的配置和Webpack一大串plugins的写法差异。实际上Vite的插件机制和配置结构更简单，需要什么直接装对应插件，常用配置一屏就能写完。别名配置、开发代理、静态资源处理这些高频需求，Vite都内置了很直接的支持。

3.4 Vue3+TS必备的几个类型操作

Vue3结合TypeScript后，常用的技巧其实就几个。defineProps和defineEmits是编译宏，写在script setup里不需要手动导入，可以直接接收泛型参数定义类型：

interface UserCardProps { user: UserInfo; showActions?: boolean; } const props = withDefaults(defineProps(), { showActions: true }); const emit = defineEmits<{ (e: 'select', user: UserInfo): void; (e: 'delete', id: number): void; }>();

这样的写法在父组件使用时，编辑器就能提示props和emit的准确类型，传错字段直接报错。defineModel是Vue3.4之后推荐的v-model新写法，封装表单组件时不用再手动写modelValue和update:modelValue，一个宏全部搞定。

类型工具方面，typeof、keyof、infer在真实项目中每天都用。对后端同学来说，TypeScript里最像Java泛型的就是泛型约束，比如写一个useRequest工具函数，传入一个API方法就能返回其返回值类型，这种抽象方式掌握之后会对TS的类型系统理解深很多。如果面试考TypeScript，把type和interface的区别、泛型约束、类型守卫这几个点讲清楚，基本就不会漏。

4. 前后端真正的连接点：接口契约与类型共享

4.1 用OpenAPI把后端的类型“送”给前端

前后端类型断层是最影响开发效率的问题之一。后端定义了响应结构，前端人肉翻译成TS接口，后端一改字段前端就得满项目找引用。解决这个问题的思路是把契约定义做唯一化：后端代码是唯一事实来源，通过springdoc-openapi自动生成OpenAPI描述文件，前端再用openapi-typescript把它转成TS类型。

实际流程是：后端加springdoc-openapi依赖，配置好扫描路径，启动后访问/swagger-ui或/v3/api-docs就能看到接口文档，同时拿到一份JSON描述文件。然后前端在package.json里加一个脚本：

{ "scripts": { "gen:api": "openapi-typescript http://localhost:8080/v3/api-docs -o src/api/schema.d.ts" } }

执行之后src/api/schema.d.ts里就有全部接口对应的TS类型了。后端改字段，前端重新生成一次，类型不匹配的地方编译期就会暴露。这套流程在我参与过的项目里实测下来，前后端联调时间至少能节省三成以上。

需要注意的是，依赖自动生成的类型会有些复杂，比如路径参数、枚举值、嵌套对象都会生成对应类型。前端做封装时不要直接改生成文件，应该基于生成类型做二次封装，比如axios请求函数里用泛型指定响应类型，这样生成的schema.d.ts更新时不会冲突。

4.2 一次登录认证流程中的前后端配合

用SpringBoot3+Vue3+TS做登录认证，最常见的方案是JWT无状态鉴权。后端在登录接口校验用户名密码，成功后签发access token和refresh token；前端把token存在内存或localStorage中，axios请求拦截器统一挂Authorization头，响应拦截器捕获401后自动刷新token。

前端这部分如果用TypeScript写，可以把核心逻辑收敛到一个auth模块里：

interface TokenPair { accessToken: string; refreshToken: string; } export function useAuth() { const tokens = ref(null); async function login(username: string, password: string) { const { data } = await api.auth.login({ username, password }); tokens.value = data; } function logout() { tokens.value = null; } return { tokens, login, logout }; }

路由守卫方面，Vue Router的beforeEach里判断用户是否有token、是否需要拉取用户信息、页面是否需要特定权限。注意一点：不要把路由守卫里的逻辑写得太重，每次跳转都请求用户信息会拖慢首屏体验。常见的做法是内存里缓存用户信息，只有在刷新页面时才重新拉取。

4.3 后台管理系统常见的权限模型参考

如果你要做一个后台管理系统，最省力的方式是在GitHub上找一个成熟的开源模板，比如vue-vben-admin或Geeker-Admin，再结合若依这类后端脚手架。2026年了，从零手写一套基础后台的前端框架（登录、布局、菜单、权限指令、动态路由）大概要两到三周，有现成模板的加持，这个时间能压缩到几天。

权限模型方面，最通用的是RBAC：用户-角色-菜单/按钮权限。前端层面有两个关键点：一是通过路由meta的permission字段做菜单和路由的动态渲染，二是写一个v-permission自定义指令控制按钮是否显示。别把权限判断逻辑散落各处，建议统一封装成一个usePermission组合式函数，组件内只调用hasPermission方法。

动态路由实现时有个坑：addRoute反复添加同一条路由会报错或覆盖，需要在登出、切换角色时用removeRoute清理。还有，异步添加路由后页面可能瞬间白屏，最常见的原因是首次访问时路由还没注册完，需要配合addRoute后重新next导航一次。若依Vue3版本里就能看到类似的处理逻辑，直接参考成熟实现是最高效的路子。

5. 实操落地：SpringBoot3+Vue3+TS全栈工程搭建

5.1 后端初始化：起步依赖与基础配置

用Spring Initializr生成工程时，我建议至少勾上这几个依赖：Spring Web、Spring Security、OAuth2 Resource Server、Spring Data JPA或MyBatis-Plus、Validation、Lombok。数据库先按你本地环境选，MySQL或PostgreSQL都行，关键是确保驱动版本和SpringBoot3兼容。

后端工程基本配置里，有三件事要做对。第一是application.yml里设置好数据源和JPA或MyBatis的方言；第二是配置springdoc-openapi暴露接口文档；第三是写一个最基础的登录接口，并让SecurityFilterChain里放行/auth/**路径。等这套骨架能跑通，再往里面加业务模块就顺风顺水。

很多从SpringBoot2迁移过来的同学会卡在MyBatis-Plus的配置变化上，注意MyBatis-Plus从3.5.3开始分出了mybatis-plus-spring-boot3-starter这个专用starter，别选错依赖。另外如果你用MyBatis-Plus，分页插件的配置在SpringBoot3中也建议使用MybatisPlusInterceptor的Bean注册方式。

5.2 前端初始化：Vite创建项目并接入TS

创建Vue3+TS工程最直接的方式是：

npm create vue@latest

按提示选择TypeScript、Vue Router、Pinia、ESLint、Prettier，一套配置齐全的工程就出来了。之后安装UI组件库，我一般用Element Plus，配合自动导入插件，组件库使用体验接近按需加载零配置的形态。

工程结构上，我会按src/api、src/composables、src/views、src/router、src/stores、src/types划分，每个模块的页面和逻辑分开。api目录里按业务模块拆分接口文件，统一从schema.d.ts引入类型；stores统一放Pinia的状态定义；types放全局类型和枚举。这个结构看起来很常规，但就是这些常规的规范能在项目膨胀之后保住可维护性。

5.3 联调配置：开发代理与跨域处理

前后端分离开发时，跨域是第一道坎。Vite开发服务器配代理很简单，在vite.config.ts里：

export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } });

这样前端请求/api/xxx会被代理到后端，浏览器里看不到跨域报错。后端不需要额外配CORS，只需要在Spring Security里把/error和需要放行的路径放行。但如果前后端是分开部署的，比如前端静态文件在Nginx上，后端在独立服务上，那就得靠Nginx的proxy_pass或者后端配CORS策略来解决。

我见过很多团队在开发环境配了代理，部署到测试环境时却忘了同步Nginx配置，导致页面能打开但接口全部请求失败。建议项目文档里明确写入“开发环境走Vite代理，生产环境走Nginx代理”，并且在前端代码里把API请求路径统一加到/api前缀，这样环境切换时只需要改代理配置，不用改代码。

5.4 可视化大屏的适配方案与ECharts问题

做可视化大屏是Vue3项目里很常见的一类需求，但大屏适配往往是最让人头疼的部分。常用的方案有两种：一种是rem适配，通过postcss-pxtorem把px转rem，配合flexible动态设置根字体大小；另一种是scale方案，整个大屏容器按设计稿比例缩放。

我踩过最大的坑是postcss-pxtorem对ECharts不生效。原因很明确：postcss-pxtorem只处理CSS文件中的px，而ECharts的尺寸和组件配置是通过JavaScript设置的内联样式或canvas绘制，postcss根本扫描不到。常见解决办法有两个：一是在postcss-pxtorem配置里用selectorBlackList排除掉大屏页面，改用JavaScript动态计算尺寸；二是大屏统一用scale缩放方案，这样ECharts配置里的px不会因为rem转换产生偏差。

如果你对ECharts在大屏里的适配“原理”还不清楚，我可以简单说下：rem方案的核心是根元素字体大小随视口变化，但canvas绘图和SVG的内部坐标系不会自动跟着rem变化，必须手动传入换算后的尺寸。所以我的建议是，凡是涉及ECharts图表的页面，优先用scale方案或者自己写一个useEchartResize组合式函数，监听容器尺寸变化并调用chart.resize()，这才是最稳定的。

6. 高频问题排查与避坑实录

6.1 若依Vue3 TS项目报错的三大原因

“若依Vue3 TS版本报错”是GitHub issue和社区里极为高频的问题。我总结下来，大部分报错都集中在三类场景。

第一类是vue-tsc类型检查报错。若依的工程模板对TS类型要求比较严格，新加的代码如果类型推导不完整，比如ref()没有给泛型、props没有定义类型，vue-tsc会在构建时直接失败。解决办法是了解vue-tsc的报错规则，把类型补全，或者临时关闭严格模式，但不建议长期关。我的建议是团队内统一一段TS类型声明规范和常用写法模板，从源头减少这类错误。

第二类是组件导入路径或命名空间导致的“找不到模块”错误。若依这类中后台项目里，很多组件使用统一注册方式，如果你在个别页面直接import了某个未被注册的组件，或者路径的大小写写错了，就会报错。解决方案其实很简单，就是统一用路径别名@来引用，不要用相对路径到处找；如果确认组件存在但还是报错，优先检查组件文件名大小写、index文件是否有默认导出。

第三类是版本不匹配问题。若依前端经常升级依赖版本，比如Element Plus从某个小版本升到另一个小版本时，API有细微变化，但若依官方文档没同步更新，导入旧版写法就会报错。遇到这个问题，最靠谱的方式是查看项目的package-lock.json锁定版本，或者直接用官方推荐的版本区间安装依赖，不要随手把依赖全都升级到最新。

6.2 TypeScript 7.0来了：tsconfig该改了

TypeScript 7.0在2026年是个热点，尤其是“选项‘baseurl’已弃用，并将停止在TypeScript 7.0中运行”这条提示，不少项目升级之后tsconfig配置报错。之前很多项目的tsconfig里都配了baseUrl和paths来做模块别名，TS7.0把baseUrl的职责移除了，路径映射直接通过paths配置相对tsconfig所在目录的路径即可。

迁移到TS7.0时，tsconfig里如果还有baseUrl，建议直接删掉，保留paths并确保paths里的映射是相对tsconfig文件位置的。比如：

{ "compilerOptions": { "paths": { "@/*": ["./src/*"] } } }

前端项目里如果配置了vue-tsc，还要注意typescript版本和vue类型工具之间的兼容性。社区里已经出现过“vue类型工具与现有TypeScript 7不兼容”的警告，遇到这种情况不要硬顶着插件版本冲突硬上，优先查看Vue官方文档推荐的TypeScript版本区间，把typescript降到对应版本即可解决。

6.3 技术栈组合下那些隐蔽的小毛病

除了上面两大高频问题，还有几个我实际遇到过的坑，拿出来分享给准备上这套技术栈的读者。

第一是Vue3中props赋值给data导致的响应性丢失。很多从Vue2转过来的习惯是this.xxx = this.props.xxx，但在Vue3里直接赋给ref或reactive后，子组件内部的数据不会随父组件props变化而更新。正确做法是用computed构建派生状态，或者用watch监听props变化后再更新本地状态。如果只是透传，直接用props计算属性或模板表达式即可。

第二是Vue3项目在Edge浏览器里偶尔出现右上角最小化按钮无法关闭的问题。这个其实是浏览器和页面交互的极个别场景，跟Vue3本身没有必然关系，但出现时排查难度很高。我的经验是优先检查页面里是否有全局事件监听器阻止了默认行为，比如document.onmousemove、window.onblur等，以及body是否被设置了overflow:hidden导致滚动事件穿透。彻底解决不了的话，试着清空浏览器缓存或关闭硬件加速，多半能临时恢复。

第三是pxtorem对ECharts不生效，这个在上一节说过了。再补充一点都是大屏项目适配时的通病：设计稿是1920的，结果在1366的笔记本上测试时，大屏整体布局发生错乱。这种问题别指望纯CSS能解决，用最基础的媒体查询加大屏适配方案一起上，才能覆盖大多数屏幕。

6.4 常见问题速查表

这套速查表是我平时排查问题时最常用的目录级总结，遇到类似情况先对照一遍，能省下不少时间。

我个人在实际操作中的体会是，这套技术栈组合虽然每部分都已经很成熟，但真把它们串起来做项目时，问题往往出在“版本兼容”和“工程规范”上，而不是技术本身。SpringBoot3、Vue3和TypeScript各自的官方文档已经足够细致了，但跨技术栈之间的集成细节，还是得靠实际踩坑一点点积累。最后再分享一个小技巧：在项目早期就把OpenAPI类型生成和前端代理配置搭好，后面每一天的开发都会觉得当初这个决定做得太对了。