1. 项目概述为什么一个音乐播放器的部署比写代码更值得花时间琢磨“AI编码工具可以随便选部署才需要挑平台”——这句话我是在把Codex生成的音乐播放器从本地开发环境推到线上时被连续三次502错误和一次数据库连接超时逼出来的。不是夸张是实打实踩坑后的真实体会。你用Codex、Cursor或者GitHub Copilot写完一个带歌词同步、进度条拖拽、播放列表管理的H5音乐播放器可能只花了20分钟但当你想把它真正跑起来、能被朋友点开链接就听、能扛住几十人同时访问、能稳定续播一整晚不掉线那接下来的4小时全在跟平台较劲。这次我选的是莫一云不是因为它是“最火”的而是它在轻量级Web服务静态资源托管MySQL基础版这三者的组合上给出了最干净的控制台、最透明的计费逻辑以及最关键的一点对前端构建产物尤其是Vite打包后的dist/目录做了原生支持不需要你手动改Nginx配置或写.htaccess重写规则。很多人看到“莫一云”第一反应是“小众”但恰恰是这种没被过度包装的平台在部署环节反而少了很多隐藏陷阱。它不强制你用它的CLI工具链不绑架你的CI流程也不在后台偷偷给你加一层反向代理层导致WebSocket连接失败——而这些恰恰是我在用另外两个主流平台部署同一套APlayerCodex生成的歌词同步逻辑时反复遇到的底层问题。所以这篇不是教你怎么用Codex写播放器而是聚焦在当代码已经写完、测试通过、本地运行完美下一步——把它稳稳地放在云上让每一个HTTP请求都落在正确的文件上让每一次/api/song/next调用都拿到真实数据让歌词滚动帧率保持60fps不卡顿——这个过程里平台选择到底在决定什么它决定的是你能不能在凌晨两点接到用户反馈说“歌词不同步了”之后3分钟内定位到是CDN缓存没刷新而不是花40分钟排查是不是平台自动注入的JS脚本干扰了requestAnimationFrame的执行时机。2. 核心思路拆解为什么“随便选AI工具”成立而“挑平台”是刚需2.1 AI编码工具的本质是高级代码补全不是运行时环境先说清楚一个前提Codex也好Copilot也罢它们输出的从来不是“可执行程序”而是一段符合当前上下文语义的、语法正确的源码文本。它不会帮你装Node.js不会替你配Webpack更不会在你npm run build失败时告诉你package.json里build脚本少了个空格。它只是个极其聪明的“键盘侠”你告诉它“用APlayer实现一个支持LRC歌词同步的音乐播放器”它就给你吐出HTML结构、CSS样式、JavaScript初始化逻辑甚至帮你把fetch(/api/songs)的接口调用和错误处理都写好了。但这段代码要跑起来依然得走完整前端工程链路依赖安装 → 模块解析 → 构建打包 → 静态资源分发 → 浏览器加载执行。AI工具在这个链条里只参与了最前端的“输入→文本生成”环节后面所有环节它既不感知也不负责。所以你说“随便选”本质上是指只要它能准确理解你的自然语言指令并输出符合现代前端工程规范的代码比如ES6模块、Vite兼容语法、TypeScript类型注解那它就是合格的。Codex在音乐播放器这类DOM操作密集、API交互明确的场景下确实表现稳定——它知道APlayer的lrc选项怎么配知道如何监听timeupdate事件去驱动歌词高亮甚至能写出用IntersectionObserver做懒加载的逻辑。但它的输出永远是一份“待编译的源码”不是“开箱即用的Docker镜像”。这就决定了AI工具选型的门槛其实是你的需求描述能力而不是平台兼容性。2.2 部署平台的核心战场在“静态”与“动态”之间划那条线真正的分水岭出现在代码完成之后。你手里的产物是什么如果是纯静态页面HTML/CSS/JS JSON数据文件那部署就是“扔上去就行”几乎所有平台都能胜任。但现实中的音乐播放器几乎不可能是纯静态的。哪怕你把歌曲MP3文件全放CDN上播放列表、用户收藏、播放历史、歌词文件路径映射——这些动态数据必然需要后端支撑。Codex生成的播放器代码里通常会包含类似这样的调用// Codex生成的典型代码片段 async function loadPlaylist() { const res await fetch(/api/playlist); if (!res.ok) throw new Error(Failed to load playlist); return res.json(); }这个/api/playlist指向哪里它背后是Node.js Express服务是Python Flask还是直接读取一个playlist.json文件这个决策直接锁死了你的部署平台选择。莫一云之所以适配这次项目是因为它提供了“静态网站托管 云函数Serverless Function”的组合方案。我把前端dist/目录直接上传到静态托管空间同时用云函数写了一个极简的Express路由只响应GET /api/playlist和GET /api/song/:id数据源直接连莫一云自带的MySQL实例。整个后端逻辑不到50行代码没有数据库连接池管理没有JWT鉴权初期版本暂未开放用户登录但它足够轻、足够快、足够隔离——云函数每次冷启动耗时约300ms热启动基本在10ms内对于播放列表这种读多写少的场景完全够用。而如果我当初选的是某个主打“全栈一体化”的平台它可能会强制你用它的专属框架比如要求你把Express封装成它定义的Handler格式或者把MySQL绑定在另一个付费更高的“专业版”套餐里甚至在静态资源路径里悄悄加一层代理导致fetch(/api/...)实际发到了它自己的网关再由网关转发——这种看似“省事”的设计恰恰是后期排查cc switch local proxy failed while handling codex endpoint /responses这类报错的根源。因为Codex生成的代码是按标准RESTful约定写的它默认/api/就是同域下的相对路径一旦平台在中间插了一层不可见的代理而文档又没明确说明你就得花半天时间抓包确认请求到底发去了哪。2.3 莫一云的“克制”设计为什么它成了这次部署的最优解莫一云没有试图做“全能选手”它的产品矩阵很清晰静态托管支持自定义域名、HTTPS强制、缓存策略设置、404重定向规则云函数支持Node.js/Python运行时内存/超时时间可调冷启动时间公开标注云数据库MySQL 5.7/8.0可选连接地址、端口、用户名密码全部明文可见无隐藏代理层网络配置安全组规则可精细控制允许你单独放开云函数对数据库的访问IP段而不是“全开或全关”。这种“模块化、可拆解、参数透明”的设计在部署音乐播放器这种中小规模应用时优势立刻凸显。比如歌词同步功能Codex生成的代码依赖audio元素的currentTime属性实时计算当前行这要求音频文件必须支持HTTP Range请求即断点续传。我测试发现莫一云静态托管对MP3文件默认就启用了Accept-Ranges: bytes响应头而某竞品平台需要手动开启“大文件优化”开关否则移动端拖拽进度条会卡死。再比如数据库连接莫一云MySQL的连接地址是mysql://user:passxxx.moyiyun.com:3306/dbname我直接把这个字符串塞进云函数的环境变量用mysql2库连接全程无任何中间件转换。而另一家平台它的数据库连接串格式是mysql://user:passproxy.xxx.com:3306/dbname表面一样但proxy.xxx.com背后是个四层负载均衡它会在连接建立后插入一个TCP层的健康检查心跳包导致某些精简版MySQL客户端比如云函数里用的mysql而非mysql2在空闲30秒后自动断连——这个细节它的文档里只字未提我是在日志里看到Error: Connection lost: The server closed the connection.才顺藤摸瓜找到的。所以“挑平台”挑的不是名气而是它是否愿意把底层网络、存储、计算的边界清清楚楚地画给你看。莫一云做到了而且做得足够朴素。3. 实操细节解析从Codex代码到莫一云上线的完整链路3.1 Codex生成代码的预处理不是拿来就能用关键在“剥离”Codex输出的播放器代码通常是一个完整的index.html单页里面内联了CSS和JS或者引用了相对路径的./style.css和./main.js。这种结构在本地开发时没问题但放到莫一云静态托管上会立刻遇到路径问题。莫一云静态托管的根目录对应的是你上传ZIP包的顶层目录。如果你直接把Codex生成的整个文件夹含index.html、style.css、main.js压缩上传那么index.html里写的link relstylesheet href./style.css是能正常加载的。但问题出在API调用上——Codex生成的JS里fetch(/api/playlist)这个路径在静态托管环境下会被浏览器直接发到https://yourdomain.com/api/playlist而莫一云静态托管本身不处理任何/api/路径它只会返回404。解决方案不是改JS代码而是利用莫一云的“重定向规则”。在莫一云控制台的静态托管设置里有一项“自定义404页面与重定向”你可以添加一条规则源路径目标路径类型状态码/api/*https://your-function-name.moyiyun.com/$1代理200这里的关键是$1它代表匹配到的*部分。比如浏览器请求/api/playlist就会被代理到https://your-function-name.moyiyun.com/playlist。这样前端代码完全不用动所有/api/开头的请求自动转发给云函数。但注意这个代理是HTTP层的不是DNS层的所以云函数的域名必须是莫一云分配的二级域名xxx.moyiyun.com不能是你自己的自定义域名——这是平台限制也是为了安全隔离。我试过用CNAME把api.yourdomain.com指向云函数结果发现跨域问题更难解因为浏览器会把https://yourdomain.com和https://api.yourdomain.com视为不同源而fetch默认不带credentials导致Cookie无法传递。所以老老实实用平台给的域名是最省心的。3.2 云函数开发50行代码撑起整个后端莫一云云函数的开发体验意外地接近本地Node.js开发。我创建了一个名为music-api的函数运行时选Node.js 18.x内存设为256MB足够应付几百QPS超时设为30秒音频元数据查询一般200ms内完成。函数入口文件是index.js内容如下const mysql require(mysql2/promise); // 从环境变量读取数据库配置 const pool mysql.createPool({ host: process.env.DB_HOST, port: parseInt(process.env.DB_PORT), user: process.env.DB_USER, password: process.env.DB_PASS, database: process.env.DB_NAME, waitForConnections: true, connectionLimit: 10, queueLimit: 0 }); exports.handler async (event, context) { // 解析URL路径提取API端点 const path event.path || /; const method event.httpMethod || GET; try { if (path /playlist method GET) { const [rows] await pool.execute(SELECT id, title, artist, duration, lrc_path FROM songs ORDER BY id); return { statusCode: 200, headers: { Content-Type: application/json; charsetutf-8 }, body: JSON.stringify(rows) }; } if (path.match(/^\/song\/\d$/) method GET) { const songId path.split(/)[2]; const [rows] await pool.execute( SELECT id, title, artist, duration, mp3_url, lrc_content FROM songs WHERE id ?, [songId] ); if (rows.length 0) { return { statusCode: 404, body: Song not found }; } return { statusCode: 200, headers: { Content-Type: application/json; charsetutf-8 }, body: JSON.stringify(rows[0]) }; } return { statusCode: 404, body: Not Found }; } catch (error) { console.error(API error:, error); return { statusCode: 500, body: Internal Server Error }; } };提示莫一云云函数的event对象结构和AWS Lambda高度兼容event.path就是请求的路径event.httpMethod是HTTP方法。这降低了迁移成本。部署前我需要把mysql2包打进函数ZIP包。莫一云支持在线编辑也支持上传ZIP。我选择本地开发npm init -y npm install mysql2 --save然后把node_modules/mysql2和index.js一起压缩。注意mysql2的体积不小约8MB莫一云免费版函数ZIP包上限是50MB完全够用。环境变量在控制台里单独配置DB_HOST、DB_PORT等值直接从莫一云数据库控制台的“连接信息”面板复制粘贴。这里有个实操心得DB_PORT一定要用parseInt()转成数字因为环境变量读出来全是字符串mysql2的port选项必须是number类型否则连接会静默失败日志里只显示connect ETIMEDOUT根本看不出是类型问题。3.3 数据库建表与初始化用最简SQL搞定核心数据结构莫一云MySQL实例创建后我用它的Web版phpMyAdmin控制台里点击“数据库管理”就能进入执行建表SQL。音乐播放器的核心就两张表-- 歌曲主表 CREATE TABLE songs ( id INT NOT NULL AUTO_INCREMENT, title VARCHAR(255) NOT NULL COMMENT 歌曲标题, artist VARCHAR(255) NOT NULL COMMENT 歌手, duration INT NOT NULL COMMENT 时长秒, mp3_url VARCHAR(500) NOT NULL COMMENT MP3文件URL, lrc_content TEXT COMMENT LRC歌词内容纯文本, lrc_path VARCHAR(255) COMMENT LRC文件路径用于APlayer的lrc选项, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 插入测试数据 INSERT INTO songs (title, artist, duration, mp3_url, lrc_content, lrc_path) VALUES (晴天, 周杰伦, 245, https://cdn.example.com/qingtian.mp3, [00:00.00]作词周杰伦\n[00:05.20]作曲周杰伦\n[00:10.50]故事的小黄花..., https://cdn.example.com/qingtian.lrc), (夜曲, 周杰伦, 278, https://cdn.example.com/yequ.mp3, [00:00.00]一群嗜血的蚂蚁..., https://cdn.example.com/yequ.lrc);注意lrc_content字段存的是LRC文件的原始文本内容不是文件路径。APlayer的lrc选项既可以接受URL也可以接受字符串。我选择存字符串是因为云函数返回JSON时可以直接把lrc_content字段塞进去前端JS拿到后直接赋值给APlayer的lrc属性避免额外一次fetch请求。这对移动端尤其友好减少请求数就是减少耗电。3.4 前端构建与上传Vite打包的三个关键配置Codex生成的代码我本地用Vite重构了一遍不是为了炫技而是解决三个硬性问题环境变量注入把云函数的代理地址作为import.meta.env.VITE_API_BASE_URL注入到构建产物里Base路径修正莫一云静态托管的根目录就是你的站点根目录所以base必须设为/静态资源哈希开启build.rollupOptions.output.assetFileNames确保CSS/JS文件名带哈希避免浏览器缓存旧版本。vite.config.js关键配置如下export default defineConfig({ base: /, // 必须设为根路径 build: { rollupOptions: { output: { assetFileNames: ({ name }) { if (/\.(png|jpe?g|gif|svg)$/.test(name)) { return assets/[name].[hash][extname]; } if (/\.css$/.test(name)) { return assets/[name].[hash][extname]; } return assets/[name].[hash][extname]; } } } }, define: { __APP_VERSION__: JSON.stringify(process.env.npm_package_version || 1.0.0) } });构建命令是npm run build产物在dist/目录。上传时我直接把dist/文件夹整个拖进莫一云静态托管的上传窗口。上传完成后莫一云会自动解压并将dist/index.html作为默认首页。这里有个易错点如果你的dist/目录里还有dist/dist/即嵌套了两层上传后首页会变成https://yourdomain.com/dist/index.html而不是https://yourdomain.com/。所以务必确认dist/是顶层目录里面直接是index.html、assets/等。4. 关键环节实现歌词同步、音频加载、错误兜底的实战打磨4.1 APlayer歌词同步的底层机制不是魔法是精确的时间映射Codex生成的歌词同步逻辑核心在于timeupdate事件的监听和lrc内容的解析。APlayer内部会把LRC文本按行分割每行提取出时间戳如[00:10.50]和歌词文本然后在音频播放时根据audio.currentTime的值遍历所有时间戳找出当前应该高亮的行。这个过程看似简单但有三个隐藏雷区时间戳精度LRC标准时间戳是[mm:ss.xx]其中xx是百分之一秒。但浏览器audio元素的currentTime返回的是浮点数秒如10.498精度受系统定时器影响可能有±10ms偏差。APlayer的默认匹配算法是“找小于等于当前时间的最大时间戳”这会导致高亮延迟。我的解决方案是在云函数返回的lrc_content里把所有时间戳统一转成毫秒整数并在前端JS里预处理// 预处理LRC转成毫秒数组 function parseLrc(lrcText) { const lines lrcText.split(\n); const timeLyrics []; const regex /\[(\d{2}):(\d{2})\.(\d{2})\](.*)/; lines.forEach(line { const match line.match(regex); if (match) { const minutes parseInt(match[1], 10); const seconds parseInt(match[2], 10); const centiseconds parseInt(match[3], 10); const timeMs (minutes * 60 seconds) * 1000 centiseconds * 10; const lyric match[4].trim(); if (lyric) timeLyrics.push({ time: timeMs, text: lyric }); } }); // 按时间升序排序 return timeLyrics.sort((a, b) a.time - b.time); }滚动性能APlayer默认用CSStransform: translateY()做歌词滚动但在低端安卓机上频繁触发transform会导致掉帧。我改用position: absolutetop值控制配合will-change: top开启GPU加速.aplayer-lrc-content { position: relative; height: 200px; /* 固定高度 */ overflow: hidden; } .aplayer-lrc-paragraph { position: absolute; left: 0; width: 100%; text-align: center; transition: top 0.2s ease; will-change: top; }空歌词兜底当lrc_content为空或解析失败时APlayer会显示空白。我在初始化时加了一层判断if (song.lrc_content song.lrc_content.trim()) { player.lrc parseLrc(song.lrc_content); } else { player.lrc [00:00.00]暂无歌词; }4.2 音频加载的容错设计从404到503每一层都要拦截MP3文件放在CDN上最大的风险不是带宽不够而是CDN节点回源失败或者源站临时不可用。Codex生成的代码通常只处理了canplay和error事件但实际中error事件的event.target.error.code只有4种值MEDIA_ERR_ABORTED等无法区分是404文件不存在还是503源站挂了。我的做法是在云函数的/song/:id接口里增加一层CDN健康检查。当查询到歌曲记录后先用node-fetch发起一次HEAD请求到mp3_urlconst { default: fetch } await import(node-fetch); // ... 在查询歌曲后 try { const headRes await fetch(song.mp3_url, { method: HEAD }); if (!headRes.ok) { console.warn(MP3 HEAD check failed for ${song.mp3_url}: ${headRes.status}); // 记录告警但不中断让前端自己处理 } } catch (e) { console.error(CDN health check failed:, e); }前端则监听audio的stalled事件缓冲停滞和suspend事件加载暂停一旦触发立即切换备用音源或提示用户audio.addEventListener(stalled, () { console.log(Audio stalled, trying backup source); audio.src song.backup_mp3_url || song.mp3_url; audio.load(); }); audio.addEventListener(suspend, () { showNotification(网络不稳定正在重试...); });4.3 错误监控与日志闭环让每个500错误都说话莫一云提供了云函数日志查看功能但默认只保留最近7天且搜索功能较弱。我做了两件事提升可观测性结构化日志所有console.error()都输出JSON格式包含timestamp、functionName、errorType、stackconsole.error(JSON.stringify({ timestamp: new Date().toISOString(), functionName: music-api, errorType: error.constructor.name, message: error.message, stack: error.stack, path: event.path }));前端错误上报在播放器JS里捕获全局未处理的Promise拒绝和window.onerror并发送到云函数的一个专用上报接口window.addEventListener(error, (e) { reportError(js-error, { message: e.message, filename: e.filename, lineno: e.lineno }); }); function reportError(type, data) { fetch(/api/report-error, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ type, data, url: window.location.href }) }); }云函数里对应的/report-error路由把日志存到MySQL的error_logs表字段包括type、data_json、url、created_at。这样当用户说“歌词不同步”我就能在数据库里搜url LIKE %qingtian% AND type js-error快速定位是哪个JS文件哪一行出了问题。5. 常见问题与排查技巧实录那些让你半夜爬起来的报错5.1 “cc switch local proxy failed while handling codex endpoint /responses” —— 这不是Codex的锅这个报错我在本地用VS Code接入Codex调试时见过无数次。它的本质是VS Code的Codex插件或Cursor等IDE在尝试把你的/responses请求通过本地代理转发给Codex后端。但当你在莫一云上部署后这个报错就消失了因为它只存在于本地开发环境。真正要警惕的是这个报错出现时往往意味着你的本地fetch调用目标地址写错了。比如你在index.html里写了script // 错误写法指向本地localhost fetch(http://localhost:3000/api/playlist) /script而你应该用相对路径script // 正确写法让浏览器自动拼接当前域名 fetch(/api/playlist) /script注意绝对路径http://localhost:3000/...在部署后必然失败因为生产环境没有localhost:3000这个服务。Codex生成的代码有时会混用绝对和相对路径必须人工检查一遍。5.2 “doris安装部署”、“ollama本地部署”等热词的启示别被名词吓住看透技术栈分层刷到“doris安装部署”、“ollama本地部署”这些热词很容易焦虑“我的音乐播放器要不要也上Doris做日志分析要不要用Ollama跑个本地大模型推荐歌单”——大可不必。技术选型的第一原则是“够用就好”。Doris是MPP架构的OLAP数据库适合PB级日志分析Ollama是本地运行大模型的工具需要至少16GB显存。而我的播放器日活估计就几百人日志量每天不到10MB用MySQL的error_logs表存着配合SELECT COUNT(*) GROUP BY DATE(created_at)就能看出哪天报错突增。Ollama更不用提推荐歌单这种需求用一个简单的协同过滤算法比如基于用户收藏相似度50行Python就能搞定何必拉起一个7B参数的大模型这些热词的真正价值是提醒你当你的业务规模真的涨到百万用户、日志TB级、需要实时个性化推荐时这些技术才是你的备选方案。现在它们只是噪音。5.3 “h5音乐播放器歌词同步怎么弄的” —— 同步的终极答案用Web Audio API重写时间轴所有基于audio元素的歌词同步都受限于浏览器音频引擎的精度。实测下来在iOS Safari上timeupdate事件的触发间隔可能长达500ms导致歌词高亮严重滞后。终极解法是绕过audio用Web Audio API手动解码MP3并驱动时间轴。但这需要引入ffmpeg.wasm或mp3-decoder库增加1MB以上的JS体积对首屏加载是灾难。我的折中方案是在timeupdate事件里用performance.now()打时间戳计算两次触发之间的实际间隔动态调整歌词高亮的阈值。比如正常间隔是200ms如果检测到连续3次间隔400ms就降低高亮匹配的宽容度提前高亮下一行。代码不多但效果显著let lastTimeUpdate 0; let timeDrift 0; audio.addEventListener(timeupdate, () { const now performance.now(); const interval now - lastTimeUpdate; lastTimeUpdate now; if (interval 400) { timeDrift 50; // 累计漂移 } else if (interval 100) { timeDrift Math.max(0, timeDrift - 20); // 修正漂移 } const currentMs Math.floor(audio.currentTime * 1000) timeDrift; highlightLrcLine(currentMs); });5.4 “goldendb三节点部署安装”、“k8s部署教程” —— 当你开始想这些说明该重构了看到“goldendb三节点”、“k8s部署”第一反应不应该是“我也要上”而是“我的单节点MySQL是不是快扛不住了”查一下莫一云数据库监控如果CPU持续70%、连接数经常90%、慢查询日志里出现SELECT * FROM songs全表扫描那才是升级信号。目前我的播放器MySQL监控显示CPU峰值12%平均连接数3个慢查询为0。这时候去折腾K8s就像给自行车加涡轮增压——钱花了车散了。真正的扩展路径应该是先用莫一云的“读写分离”功能把SELECT请求路由到只读副本等只读副本也扛不住了再考虑分库分表。每一步都对应着真实的监控指标而不是网上热词的牵引。6. 实操心得与避坑清单来自凌晨三点的血泪总结环境变量命名陷阱莫一云云函数的环境变量如果包含.或-在Node.js里无法通过process.env.MY_VAR直接读取必须用process.env[MY.VAR]。我曾把DB_HOST写成db.host结果连接一直失败日志里连错误都不打因为process.env.db.host是undefined而mysql2的host选项默认是localhost它就默默连本地了。解决方案环境变量名只用字母、数字、下划线且全部大写。CDN缓存与LRC更新不同步我把LRC文件放在CDN上但修改后前端还是显示旧歌词。原因在于CDN缓存了*.lrc文件而我没有设置Cache-Control: no-cache。解决方法有两个一是给LRC URL加时间戳参数?v20240520二是用莫一云CDN控制台针对.lrc后缀设置缓存时间为0。我选了后者一劳永逸。云函数冷启动的“假死”现象第一次访问/api/playlist响应时间2.3秒后续都是30ms。这不是bug是冷启动。莫一云文档明确写了“首次调用需预热”但没说怎么预热。我的土办法在静态托管的index.html里加一段JS在页面加载完成后用fetch(/api/playlist, { method: HEAD })悄悄预热一次。虽然多了一次请求但用户第一次点击播放按钮时就不会卡顿了。字体图标加载阻塞渲染Codex生成的播放器有时会引用Font Awesome的CDN字体。在弱网下字体加载失败会导致播放按钮显示为方块。我的处理是用link relpreload预加载同时提供SVG内联图标作为降级link relpreload hrefhttps://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.4.0/webfonts/fa-solid-900.woff2 asfont typefont/woff2 crossorigin !-- 播放按钮 -- button classplay-btn svg viewBox0 0 24 24 width24 height24path dM8 5v14l11-7z//svg /button移动端双击放大问题iOS Safari默认允许双击放大文字这在播放器界面上很讨厌。一句CSS解决* { -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; } body { -webkit-tap-highlight-color: transparent; }最后再分享一个小技巧莫一云静态托管的“自定义404页面”不要只写“页面没找到”而是放一个自动跳转回首页的JS!DOCTYPE html html headmeta http-equivrefresh content0;url//head bodyRedirecting.../body /html这样当用户手动输入一个不存在的路径比如/admin不会看到冰冷的404而是平滑回到首页。用户体验的提升往往就藏在这种不起眼的细节里。
