为什么我坚决放弃了自建 Meting API
前言
前段时间折腾博客侧边音乐播放器，在解决了播放器不显示的问题之后，又遇到了歌单能加载、但无法播放音频的难题。网上很多教程都推荐自建 Meting API 来一劳永逸，我也差点动手操作，但最后经过一番思考，我果断放弃了这个方案，今天把我的心路历程和经验分享出来。
问题背景
当时我的播放器界面已经完全正常，歌单、封面、歌词都能正常渲染，就是无法播放。排查后发现，市面上所有公共 Meting API 基本全部失效，要么域名无法解析，要么出现跨域报错、503 服务不可用等问题，尤其是 QQ 音乐的接口，几乎没有稳定可用的。
在找不到可用公共 API 的情况下，我第一反应就是尝试在服务器上自建 Meting API，摆脱第三方接口的限制。于是我准备了完整的部署方案，包括 Docker 部署、端口占用、Nginx 反向代理、域名配置等一系列操作。
放弃自建的真实原因
风险太大，容易影响整个网站
自建 API 需要修改服务器配置、占用端口、配置反向代理，而我原本的博客环境已经非常稳定。一旦配置出错，很可能导致网站访问异常、样式错乱，为了一个音乐播放功能，冒全站出问题的风险完全得不偿失。
服务器已有端口占用，冲突风险高
当时检测发现服务器 3000 端口已经被原有程序占用，如果强行部署，会出现端口冲突，处理起来又要额外折腾，进一步增加了不稳定因素。
部署过程繁琐，中途终止会带来心理焦虑
我中途尝试启动部署，又因为担心风险手动终止操作，之后一直担心服务器会留下垃圾文件、残留容器，影响网站运行，这种心理负担完全没必要。
完全有更简单、零风险的替代方案
我最后发现，只需要把音乐平台从 QQ 音乐切换成网易云音乐，使用主题默认接口，无需任何服务器改动，就能直接稳定播放，问题瞬间解决。
最终选择
我彻底放弃了自建 Meting API 的想法，选择最简单、最稳妥的方案：切换到网易云音乐平台，清空自定义 API 配置，使用主题原生接口。不仅播放稳定，还完全不改动服务器，零风险、零折腾。
经验总结
为了小功能去大改服务器配置，是性价比极低的选择。
个人博客优先追求稳定，不要为了追求完美而盲目折腾。
公共 API 失效时，优先尝试更换平台，而不是直接自建服务。
中途终止的服务器部署操作，只要未完成最终写入，不会留下任何残留影响。
能不改动服务器，就绝不改动服务器，这是新手运维最重要的原则。