created更适合发请求，因其在响应式系统就绪而DOM未挂载时执行，可并行渲染、支持SSR且避免ref报错；mounted适用于需DOM信息的场景，如尺寸适配、视口检测或第三方库初始化。

多数情况下，created 更适合发请求，但不是因为它“更高级”，而是因为它的执行时机和能力刚好匹配大多数数据获取场景——响应式系统已就绪、DOM 尚未干扰、请求可尽早发起。

created 发请求的核心优势

这个阶段组件实例已经创建完成，data、methods、computed、props 全部可用，同时 Vue 的响应式系统已启动。这意味着你拿到的数据会自动触发视图更新，且无需等待页面渲染。

• 请求能和 DOM 渲染并行进行，缩短白屏时间
• 服务端渲染（SSR）中，created 会执行，mounted 不会，保证首屏数据一致
• 不依赖 this.$el 或 ref，避免因 DOM 未挂载导致的报错或逻辑断裂
• 适合纯数据驱动场景：用户信息、商品列表、配置项、权限菜单等

mounted 发请求的不可替代场景

mounted 的价值不在“能不能发请求”，而在于“必须等 DOM 就位才能决定发什么、怎么发”。它解决的是视图适配类问题，而非单纯的数据加载。

蓝湖代码转vue2.0+element-ui

将静态 Vue 页面(index.vue)改造为动态页面(Custom.vue)；稿源仅限 index.vue、其引用的 CSS 与资源路径，禁止参考仓库内其他文件。Invoke when user wants to transform a static Vue page into a dynamic data-driven page with Element UI components.

下载

• 需要读取容器宽度/高度后请求对应尺寸图片（如 srcset 或 CDN 动态缩略图）
• 根据元素是否进入视口做曝光埋点，再触发后续资源加载
• 第三方库初始化后才可调用其 API（如 ECharts 实例创建后 fetch 图表数据）
• Modal 或弹层类组件需等动画结束、布局稳定后再拉取内部内容

常见误用与风险提醒

两个钩子里都发同一接口，表面“保险”，实则埋下隐患：

• 重复请求造成服务压力，也可能覆盖前序响应，导致状态错乱
• 在 created 中 await 请求后立即操作 this.$refs.xxx —— 此时 ref 还不存在，会报 undefined
• 路由复用组件（如 /user/1 → /user/2）时，created 不会再次触发，若只靠它，新参数不会触发新请求
• SEO 敏感页把关键数据请求放在 mounted，可能被搜索引擎爬虫忽略，影响收录

实际项目中的协作思路

复杂页面往往不是二选一，而是分层处理：

• created 负责主体数据：文章详情、评论总数、作者信息
• mounted 检查 DOM 状态：图片容器是否加载失败？是否需要 fallback 尺寸？是否要补发懒加载项？
• 配合 watch: $route 或 beforeRouteUpdate 响应参数变化，避免生命周期“失灵”
• Composition API 中可用 onMounted + watchEffect 组合，实现更精细的依赖追踪与触发控制

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！