企业官网建设流程全解析

如果你正在准备前端面试，或者正为毕业设计找一个“拿得出手”的项目，Vue3 几乎是绕不开的关键词。但很多人在实战中会遇到一个尴尬的处境：看了不少文档，也敲过不少 demo，真正动手做一个完整项目时，却发现自己连“从哪开始拆页面”都不太确定。网易云音乐这个选题之所以适合实战，不只是因为它界面好看、功能丰富，而是它天然包含了前端项目中最高频、也最容易被面试官追问的完整链路：组件通信、状态管理、路由组织、接口封装、播放器全局控制、搜索防抖、评论加载等等。这篇文章不是带你机械地抄一遍代码，而是把这个项目的设计思路拆开讲清楚，再配合可直接运行的源码与文档，让你既能动手跑通，也真正理解每一层为什么要这样写。

先说结论：做 Vue3 实战项目，最忌讳两件事。一是只会跟着视频敲，关掉视频就不知道该写什么；二是项目做得太“玩具”，只有列表页和详情页，面试时聊不出深度。网易云音乐实战项目的好处在于，它的业务复杂度刚刚好——比后台管理系统更有前端表现力，又不像大型电商项目那样涉及过重的服务端链路。通过这个项目，你可以把 Vue3 组合式 API、Pinia 状态管理、Vue Router 路由守卫、Axios 接口拦截、组件封装与性能优化这些核心技能一次性串起来。下面我会按照从零到一的项目搭建顺序，把关键环节逐一拆解，并给出完整示例代码和排查思路。

1. 为什么是网易云音乐：这个实战项目的真正价值

选择项目题材时，很多人优先考虑“好不好做”，而不是“做完了能说明什么”。如果一个项目做完，你的简历上只能写“实现了登录、列表、详情三个页面”，那它对你面试的帮助非常有限。网易云音乐实战项目的价值不在于“音乐播放”本身，而在于它覆盖了前端面试中高频考察的几类工程问题。

第一类是数据流设计。播放器是一个典型的全局跨组件状态场景：歌曲列表页需要把当前歌曲信息传给底部播放栏，推荐页需要展示正在播放的状态，歌单详情页要维护播放队列。如果用组件 props 层层传递，代码会迅速失控。这种场景逼迫你去思考“哪些状态应该放在 Pinia 中，哪些状态应该保持组件局部”，这比背十遍“Pinia 是什么”都管用。

第二类是接口层设计。真实项目不会把请求散落在每一个组件里。你需要设计统一的 Axios 实例，处理 baseURL、超时、拦截器、错误提示，还要思考如何针对不同模块拆 API 文件。网易云音乐涉及的接口类型很丰富：有返回列表数据的 GET 请求，有需要请求参数的搜索接口，也有涉及用户登录态的接口。把这些接口统一管理之后，你的项目结构会非常接近中小型前端团队的真实工作方式。

第三类是交互复杂度。播放器需要处理播放、暂停、上一首、下一首、进度条拖动、歌词展示、播放模式切换。每一个交互背后都对应 Vue3 中的一类技术点：事件处理、计算属性、侦听器、组件 v-model 定制。尤其是“下一首”自动切换，需要同时操作 audio 元素和 Pinia 中的播放列表索引，这里的数据流设计非常值得面试时展开讲。

所以，这个项目的真实价值是“以音乐为载体的前端工程能力训练”。做完之后，你应该能回答这几个问题：整个项目的状态管理结构是怎样的？播放队列的数据流是怎么走的？接口错误统一在哪里处理？组件复用是怎么抽的？这些才是面试官真正想听到的内容。

2. 技术栈选型与核心概念梳理

在动手写代码之前，先把技术栈确定下来。这个项目推荐使用当前 Vue3 生态中最主流、也是面试中最常被问到的组合：

这里重点解释两个容易混淆的概念：组合式 API 与选项式 API 的区别，以及 Pinia 与组件本地状态的分工边界。

组合式 API（Composition API）是 Vue3 新增的逻辑复用方式。它把“按选项划分代码”改成了“按功能划分代码”。在选项式写法中，一个功能的 data、methods、watch 可能分散在文件不同位置；而在组合式写法中，同一个功能的响应式数据、计算属性、方法可以放在一起，通过setup中的函数组合起来。这个变化带来的直接好处是：当组件逻辑变复杂时，你可以把某块功能抽成自定义 Hook（Composable），在不同组件间复用。在音乐项目中，“播放进度控制”“搜索防抖”“列表加载更多”都可以抽成独立的 composable 函数，这比 mixin 更清晰，也没有命名冲突的隐患。

Pinia 是 Vue3 的状态管理库。它的核心概念比 Vuex 简单很多：Store 里可以有 state、getters、actions，不再需要 mutations。对新手来说，最需要搞清楚的问题是“什么状态应该放进 Store，什么状态应该留在组件里”。我的建议是：被多个组件共享、且需要跨页面保持一致的状态，放进 Store；只服务于单个组件内部展示的状态，保留在组件局部。音乐播放器的播放状态、当前歌曲、播放列表、播放模式这些属于前者；页面内部的加载动画开关、弹窗显隐这些属于后者。

3. 环境准备与项目初始化

开始实战前，先确认本地环境。Node.js 版本建议使用 18 或 20 LTS 版本，具体以你本机安装的版本为准。如果你用的是更高版本，一般兼容性也没有问题，但如果遇到依赖安装失败，优先检查 Node 版本。

使用 Vite 创建 Vue3 项目：

npm create vite@latest netease-music-vue3 -- --template vue

执行成功后，进入项目目录并安装依赖：

cd netease-music-vue3 npm install

接着安装路由、状态管理和请求库：

npm install vue-router@4 pinia axios

需要说明的是，当前 Vue 生态中很多工具库都已经同时支持 Vue2 和 Vue3，安装时最好通过npm install安装最新版本，并且确认依赖的 peerDependencies 没有相互冲突。如果出现类似ERR! ERESOLVE unable to resolve dependency tree的错误，多半是因为某个包的版本要求不一致，可以先查看报错信息，再尝试用npm install --legacy-peer-deps安装，但更推荐的做法是手动统一版本。

项目创建完成后，目录结构会默认生成src/components、src/App.vue、src/main.js等基础文件。我们后续需要在此基础上扩展出src/views、src/router、src/stores、src/api、src/utils等目录。为了让项目结构更清晰，建议先手动创建好目录骨架：

mkdir -p src/views src/router src/stores src/api src/utils src/components/common

这一步很多人会跳过，直接开始写页面。但在真实团队开发中，目录结构是代码可维护性的第一道保障。面试时如果被问到“你的项目如何组织”，能够清晰说出每个目录的职责，会是一个很好的加分项。

4. 路由配置与项目目录设计

在实际开发中，路由不是写几个 path 和 component 就结束的。音乐项目通常需要区分“主框架页面”和“独立页面”。主框架页面指的是带有底部 TabBar 或侧边栏的首页、发现页、我的页面，它们共享同一套布局；独立页面则是歌单详情、播放器全屏页、搜索结果页等，它们可能需要全屏展示，或者需要从任意入口跳入。

推荐的结构是：用一个布局组件包裹主框架页面，在路由配置里用 children 实现嵌套路由。这样做的好处是，布局组件只需要写一次，切换子路由时只更新 content 区域，底部播放器组件可以稳定地挂在 layout 中，不会因为页面跳转而重新渲染。

// 文件路径：src/router/index.js import { createRouter, createWebHistory } from 'vue-router' const routes = [ { path: '/', component: () => import('@/layout/MainLayout.vue'), children: [ { path: '', name: 'Home', component: () => import('@/views/HomeView.vue'), meta: { title: '发现音乐' } }, { path: 'my', name: 'My', component: () => import('@/views/MyView.vue'), meta: { title: '我的' } } ] }, { path: '/playlist/:id', name: 'PlaylistDetail', component: () => import('@/views/PlaylistDetailView.vue'), meta: { title: '歌单详情' } }, { path: '/search', name: 'Search', component: () => import('@/views/SearchView.vue'), meta: { title: '搜索' } } ] const router = createRouter({ history: createWebHistory(), routes }) router.afterEach((to) => { document.title = to.meta.title ? `${to.meta.title} · 网易云音乐` : '网易云音乐' }) export default router

路由配置中需要注意两个关键点。

第一，用@作为 src 目录别名。这个需要在 Vite 配置文件中添加resolve.alias，否则@/views/...会报解析错误。常见的做法是在项目根目录的vite.config.js中配置：

// 文件路径：vite.config.js import { fileURLToPath, URL } from 'node:url' import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } } })

第二，首页路径使用空字符串path: ''，而不是path: '/'。在嵌套路由中，如果父组件已经有/，子路由再写/会导致匹配错误。空字符串表示“父路径的默认子路由”，这是 Vue Router 4 中很常见但又容易写错的地方。

这样一个路由骨架设计好后，你在后续新增页面时只需要在routes数组里追加一个对象，不需要动布局组件。这对于多人协作或后续扩展都是非常友好的结构。

5. 接口请求封装与 API 模块拆分

接口层是前端项目中容易被忽视、但对工程质量影响极大的部分。很多新手喜欢在组件里直接写axios.get('/xxx')，一旦接口地址变更或者需要统一处理登录态，就要全局搜索替换。更成熟的做法是：先封装一个统一的请求实例，再按业务模块拆分成独立的 API 文件。

5.1 Axios 请求实例封装

首先在src/utils/request.js中创建一个 Axios 实例，配置基础 URL 和超时时间：

// 文件路径：src/utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000 }) // 请求拦截器：可以在发送请求前统一处理 token、请求参数等 service.interceptors.request.use( (config) => { const token = localStorage.getItem('music_token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }, (error) => { return Promise.reject(error) } ) // 响应拦截器：统一处理业务状态码和 HTTP 错误 service.interceptors.response.use( (response) => { const res = response.data if (res.code !== 200) { if (res.code === 401) { localStorage.removeItem('music_token') window.location.href = '/' } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message || 'Error')) } return res }, (error) => { ElMessage.error(error.message || '网络异常，请稍后重试') return Promise.reject(error) } ) export default service

这段代码看起来简单，却解决了一个非常重要的问题：接口请求失败时的处理逻辑不需要在每个页面重复写。只要在拦截器里统一定义，所有通过service发出的请求都会自动带上 token、自动处理 401 跳转、自动弹出错误消息。这会让你的代码量大为减少，也更贴近真实项目的开发方式。

需要注意的是，VITE_API_BASE_URL是一个环境变量，需要在项目根目录创建.env.development和.env.production文件来配置。例如开发环境可以指向你本地启动的后端服务地址，生产环境可以指向线上域名。这种配置方式可以避免在代码里硬编码接口地址，也方便不同环境切换。

5.2 按模块拆分接口

有了请求实例之后，再把接口按业务模块拆开。以音乐项目为例，常见的模块有：推荐模块、歌单模块、歌曲模块、搜索模块、评论模块、用户模块。每个模块一个文件，统一导出函数。

// 文件路径：src/api/search.js import service from '@/utils/request' /** * 搜索歌曲 * @param {Object} params - 搜索参数 * @param {string} params.keywords - 搜索关键词 * @param {number} params.limit - 返回数量 * @param {number} params.offset - 偏移量，用于分页 * @returns {Promise} */ export function searchSongs(params) { return service.get('/search', { params: { ...params } }) }

使用这种封装方式之后，业务组件中不需要知道底层请求是 GET 还是 POST，也不需要关心接口路径。调用时只需要：

import { searchSongs } from '@/api/search' const response = await searchSongs({ keywords: keyword.value, limit: 30 })

面试中如果你能讲清楚“为什么把接口统一封装到 api 目录”，就已经和大部分只会写.vue文件的候选人拉开了差距。这背后体现的是你对代码组织、可维护性和团队协作的理解。

6. 核心页面实战：首页推荐与歌单详情

6.1 首页推荐模块

首页推荐是用户进入项目后看到的第一个页面。它通常由 Banner 轮播、推荐歌单列表、最新音乐列表几个部分组成。这一页的核心练习点有两个：自定义组件的设计与复用，以及异步数据的加载状态管理。

推荐页的数据加载流程并不复杂，但有一个细节值得注意：多个区块的数据请求是相互独立的，应该用Promise.all并行发起，而不是逐个await。如果串行请求，页面整体加载时间会是所有接口耗时的总和；改为并行之后，耗时只取决于最慢的那个请求。

<script setup> import { ref, onMounted } from 'vue' import { getBanner, getRecommendedPlaylists } from '@/api/recommend' import BannerSwiper from '@/components/BannerSwiper.vue' import PlaylistCard from '@/components/PlaylistCard.vue' const banners = ref([]) const playlists = ref([]) const loading = ref(false) const loadData = async () => { loading.value = true try { const [bannerRes, playlistRes] = await Promise.all([ getBanner(), getRecommendedPlaylists() ]) banners.value = bannerRes.banners || [] playlists.value = playlistRes.recommend || [] } finally { loading.value = false } } onMounted(loadData) </script>

这里loading状态用try/finally保证无论请求成功还是失败都会被重置为 false。这是很多人容易忽略的细节——如果只用try/catch，在catch分支里忘记把loading置为 false，页面就会一直显示加载中。

推荐页面更重要的部分是PlaylistCard组件的封装。这个组件需要接收歌单数据对象，展示封面图、标题、播放量，并支持点击跳转到歌单详情页。设计组件时要注意：不要把跳转逻辑写死在组件内部。一个好的做法是让 Card 组件触发一个点击事件，由父组件决定跳转到哪里。这样 Card 组件可以在推荐页、搜索页、用户主页等多个位置复用。

6.2 歌单详情页

歌单详情页是“从列表进入详情”的标准场景，它训练的是动态路由参数获取、页面初始化和加载更多列表。详情页挂在/playlist/:id路径下，组件中通过useRoute()拿到route.params.id，再调用歌单详情接口。

<script setup> import { ref, watch } from 'vue' import { useRoute } from 'vue-router' import { getPlaylistDetail, getPlaylistSongs } from '@/api/playlist' const route = useRoute() const playlistDetail = ref(null) const songList = ref([]) const loadDetail = async (id) => { const res = await getPlaylistDetail({ id }) playlistDetail.value = res.playlist songList.value = res.playlist.tracks || [] } watch( () => route.params.id, (newId) => { if (newId) { loadDetail(newId) } }, { immediate: true } ) </script>

这里使用watch而不是onMounted有一个重要原因：如果用户在歌单详情页内部点击了另一个歌单的推荐链接，同一路由组件的onMounted不会重新执行，只有watch能侦听到route.params.id的变化并重新加载数据。这个问题在面试中也经常被问到：“同一个路由参数变化时，如何刷新组件的数据？”

在 vue-router 4 中，官方推荐使用watch(() => route.params.id, ...)来处理这类场景。这比在beforeRouteUpdate导航守卫里操作更符合组合式 API 的表达习惯。

7. 播放器核心：Pinia 状态管理与全局播放

播放器是整个项目中最能体现 Vue3 技术深度的模块。它涉及全局状态共享、audio 元素控制、播放列表管理、模式切换、自动播放等多个复杂逻辑。如果这一部分能实现得干净可靠，你的项目整体水平会被拉高一大截。

7.1 设计播放器 Store

播放器需要跨组件共享的状态包括：当前播放歌曲信息、播放状态（播放/暂停）、播放列表、当前列表索引、播放模式（顺序/循环/随机）。这些状态放在 Pinia 中统一管理。

// 文件路径：src/stores/player.js import { defineStore } from 'pinia' export const usePlayerStore = defineStore('player', { state: () => ({ currentSong: null, isPlaying: false, playList: [], currentIndex: -1, playMode: 'order', // order: 顺序, loop: 循环, random: 随机 currentTime: 0, duration: 0 }), getters: { // 播放模式切换时的图标提示 modeText: (state) => { const map = { order: '顺序播放', loop: '单曲循环', random: '随机播放' } return map[state.playMode] } }, actions: { playSong(song, list) { if (list && list.length > 0) { this.playList = list this.currentIndex = list.findIndex((item) => item.id === song.id) } this.currentSong = song this.isPlaying = true }, nextSong() { if (this.playList.length === 0) return if (this.playMode === 'random') { this.currentIndex = Math.floor(Math.random() * this.playList.length) } else { this.currentIndex = (this.currentIndex + 1) % this.playList.length } this.currentSong = this.playList[this.currentIndex] this.isPlaying = true }, prevSong() { if (this.playList.length === 0) return if (this.currentIndex <= 0) { this.currentIndex = this.playList.length - 1 } else { this.currentIndex -= 1 } this.currentSong = this.playList[this.currentIndex] this.isPlaying = true } } })

这个 Store 设计中有几个值得展开的设计决策。

第一，playSong(song, list)接收两个参数。这样做的好处是：当用户从歌单详情页点击某一首歌曲时，可以把整个歌单作为播放列表传入；当用户从搜索页点击歌曲时，传入的是搜索结果的列表。如果一个接口调用和状态更新逻辑散落多个组件，很容易出现“当前歌曲换了，但播放列表没换”的 bug。把“设置当前歌曲 + 关联播放列表”放在同一个 action 里，可以保证状态的一致性。

第二，nextSong()中根据播放模式实现了顺序、随机两种逻辑。这里的边界条件是：顺序播放时，如果当前是最后一首，再点下一首要回到第一首（取模运算）；随机播放时直接生成随机索引。这种实现虽然简单，但已经覆盖了播放器最核心的交互逻辑。

7.2 底部播放栏组件

底部播放栏是挂在布局组件中的全局组件，不管路由切换到哪个页面，它都固定显示在底部。这个组件直接操作audio元素，并且通过 Pinia store 中的数据控制播放行为。

<!-- 文件路径：src/components/PlayerBar.vue --> <script setup> import { ref, computed, watch } from 'vue' import { storeToRefs } from 'pinia' import { usePlayerStore } from '@/stores/player' const playerStore = usePlayerStore() const { currentSong, isPlaying, currentTime, duration } = storeToRefs(playerStore) const audioRef = ref(null) const formatTime = (time) => { const minutes = Math.floor(time / 60) const seconds = Math.floor(time % 60) return `${minutes}:${seconds.toString().padStart(2, '0')}` } const progress = computed(() => { if (duration.value === 0) return 0 return (currentTime.value / duration.value) * 100 }) watch( () => currentSong.value?.url, (newUrl) => { if (newUrl && audioRef.value) { audioRef.value.src = newUrl audioRef.value.play() } } ) const togglePlay = () => { if (!currentSong.value) return if (isPlaying.value) { audioRef.value.pause() playerStore.isPlaying = false } else { audioRef.value.play() playerStore.isPlaying = true } } const onTimeUpdate = () => { if (audioRef.value) { playerStore.currentTime = audioRef.value.currentTime } } const onLoadedMetadata = () => { if (audioRef.value) { playerStore.duration = audioRef.value.duration } } const handleEnded = () => { if (playerStore.playMode === 'loop') { if (audioRef.value) { audioRef.value.currentTime = 0 audioRef.value.play() } } else { playerStore.nextSong() } } </script>

这段代码中有一个非常关键的设计：duration是从storeToRefs解构出来的响应式对象，但 audio 元素的timeupdate事件触发频率非常高，每次触发都更新 Pinia 中的currentTime，会导致播放器组件频繁重渲染。在实际项目中，如果发现拖动进度或播放中页面有明显卡顿，可以把currentTime从 Pinia 中移到组件内部ref，只在暂停、切歌等关键节点同步到 Store。这是一个典型的性能优化点，面试时可以重点讲。

7.3 播放器与歌单的数据流

播放器模块最容易出 bug 的地方是歌单详情页与播放器之间的数据流。用户点击歌单中的某一首歌，应该发生哪些事？

1. 歌单详情页拿到当前歌单的完整歌曲列表。
2. 用户点击某一首时，调用playerStore.playSong(song, songList)。
3. 底部播放器的watch侦听到currentSong.url变化，更新audio的src并调用play()。
4. 用户点击下一首时，nextSong()更新 PlayList 和 currentIndex，底部播放器再次走watch流程。

所以关键路径是：UI 点击 -> Store action -> 状态变化 -> 底部播放器 watch -> audio 播放。理解这条链路后，你会发现播放器的代码量并没有想象中那么多，核心其实是一个单向数据流的设计。

8. 搜索模块与列表渲染优化

搜索功能几乎是大中型前端项目必备的能力。实现搜索时，最大的两个问题是：如何减少无效的接口请求，以及如何组织搜索结果的展示。

8.1 搜索防抖

用户输入搜索关键词时，如果每输入一个字符就发一次请求，会带来大量无效请求。防抖的思路是：当用户停止输入一段时间后再执行搜索。比较轻量的做法是封装一个useDebounce组合式函数：

// 文件路径：src/composables/useDebounce.js import { ref, watch } from 'vue' export function useDebounce(value, delay = 300) { const debouncedValue = ref(value.value) watch(value, (newValue) => { const timer = setTimeout(() => { debouncedValue.value = newValue }, delay) }) return debouncedValue }

然后在搜索页面中这样使用：

<script setup> import { ref, watch } from 'vue' import { useDebounce } from '@/composables/useDebounce' import { searchSongs } from '@/api/search' const keyword = ref('') const debouncedKeyword = useDebounce(keyword) const resultList = ref([]) watch(debouncedKeyword, async (newKeyword) => { if (!newKeyword.trim()) { resultList.value = [] return } const res = await searchSongs({ keywords: newKeyword, limit: 30 }) resultList.value = res.result.songs || [] }) </script>

这里还有一个细节：搜索前如果输入为空，应该清空搜索结果并 return，而不是向服务器发送一个空关键词。这个边界条件在面试中也很容易成为追问点。

8.2 长列表渲染优化

搜索结果和歌单歌曲列表都可能出现长列表。当列表数据超过几百条时，一次性渲染所有 DOM 会导致页面卡顿。优化方案通常是虚拟滚动（Virtual Scrolling），但这部分实现复杂度较高。如果项目规模有限，可以先采用一个折中方案：按需渲染，例如每次只渲染前 50 条，用户滚到底部时再追加 50 条。

实现“滚动到底加载更多”的逻辑，可以用@scroll事件判断当前滚动位置是否接近底部：

const handleScroll = (event) => { const { scrollTop, clientHeight, scrollHeight } = event.target if (scrollTop + clientHeight >= scrollHeight - 100) { currentCount.value += 50 } }

这种实现不是最高效的方案，但足够简单，也能应对大部分真实数据量。如果你在面试中被问到性能优化，可以从“虚拟滚动”“IntersectionObserver 无限滚动”“分页加载”几个方向展开深度讨论，这个项目可以作为你的实践载体。

9. 常见问题与排查思路

根据我的经验，新手在这个项目中会集中遇到以下几类问题。这里整理成表格，方便你快速定位。

第一个问题的常见原因是main.js中 Pinia、Router 的使用顺序不对。Vue3 应用中，pinia实例需要先创建，再作为插件安装。推荐在main.js中这样写：

// 文件路径：src/main.js import { createApp } from 'vue' import { createPinia } from 'pinia' import App from './App.vue' import router from './router' const app = createApp(App) const pinia = createPinia() app.use(pinia) app.use(router) app.mount('#app')

第二个问题中，跨域是本地开发最常见的问题。如果你启动的是独立的接口服务，而前端运行在localhost:5173，两者端口不同，浏览器就会拦截跨域请求。推荐在vite.config.js中配置开发代理，让前端请求走同源路径：

// 文件路径：vite.config.js export default defineConfig({ plugins: [vue()], server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true } } } })

配置代理后，前端请求/api/search时，Vite 会自动把请求转发到http://localhost:3000/api/search，从而绕过浏览器的跨域限制。这是本地联调阶段非常实用的配置。

10. 面试亮点与工程最佳实践

项目做完只是第一步，能讲清楚“为什么这样做”才是面试加分的关键。下面梳理几个在这个项目中特别值得强调的面试表达。

第一，状态管理的边界。当你介绍播放器模块时，不要只说“我用 Pinia 管理了播放状态”，而是要说清楚：哪些状态放进了 Store、哪些留在组件本地、为什么这样划分。例如currentTime可以放组件本地，而currentSong和playList必须放 Store，因为它们被多个组件共享。这种围绕“数据流边界”展开的回答，比背诵 Pinia 概念更有说服力。

第二，接口层的统一处理。你可以重点讲 Axios 拦截器里做了哪些事情，以及为什么要把接口请求封装到独立的 api 目录。画一下请求从组件到拦截器再到接口文件的完整流程，面试官会明显感受到你有工程化思维。

第三，组件复用的设计。PlaylistCard和SongItem是项目中最典型的复用组件。你可以说清楚它们接收什么 props、向外派发什么事件、为什么跳转逻辑放在父组件而不是写死在子组件内部。这些细节体现了组件设计能力。

从工程实践的角度，还有几点建议。

日志与错误监控。在 Axios 响应拦截器中，除了弹出错误提示，还可以把错误信息打印到浏览器控制台，或者统一上报到监控平台。在本地开发时，建议把请求参数、请求路径、错误码都打印出来，方便快速定位问题。平时把这些日志习惯养成，后续在公司项目里也能少踩很多坑。

命名规范。项目中的目录名、文件名、变量名尽量统一。我的建议是：组件用 PascalCase，如PlayerBar.vue；普通工具模块用 camelCase，如useDebounce.js；常量用全大写下划线，如DEFAULT_LIMIT。统一命名规范能降低协作成本，面试官看到代码时也会觉得你是一个有工程素养的候选人。

生产环境构建检查。项目开发完成后，不要只在npm run dev下测试，一定要执行npm run build和npm run preview验证生产构建是否正常。有时候开发环境跑得好好的，到了生产构建就报错，多半是因为环境变量未配置、路径引用错误或者依赖未被正确打包。提前发现这些问题，能避免很多尴尬。

如果你希望项目在面试中有更强的竞争力，可以继续考虑这几个进阶方向：移动端适配、PWA 离线缓存、歌词逐行滚动高亮、虚拟列表优化。每一个方向都值得单独展开，但核心还是先把这个基础版本跑通、讲透。项目源码和配套文档建议放在仓库中，配合 README 说明运行方式、目录结构和核心设计思路，这样面试官可以直接看到你的表达能力，而不仅仅是代码本身。

这个项目从初始化到播放器跑通，如果一步步做下来，你对 Vue3 的掌握程度会远高于单纯看文档或刷题。特别是播放器模块的数据流设计，几乎可以说是前端面试中“状态管理”问题的满分素材。建议把它当成一个完整的作品去打磨，而不是一个任务去完成。