我搭这个“我的极客空间”网站起因特别朴素每天要开一堆在线工具格式化JSON、转时间戳、生成二维码、查正则表达式书签栏塞得密密麻麻想听会儿音乐又得切到另一个标签页来回折腾特别打断心流。后来干脆自己做了个专属空间把高频工具和音乐播放器放进了同一个页面。一下从“逛工具网站”变成了“回到自己的工位”。这个项目解决的就是两件事一是把散落各处的工具集中到一个自己说了算的入口二是让音乐不再和工具抢标签页而是作为背景氛围常驻在旁边。我自己的体验是自从用了这个页面浏览器标签页从二十几个降到了五六个写代码和查资料的顺畅度提升非常明显。适合什么人参考如果你有个人站点、想折腾一个低成本的轻应用或者单纯对“怎么把多个小工具和播放器塞进一个页面”感到好奇这篇文章都值得读完。下面按我的构思、选型、实现、部署到踩坑完整过一遍。1. 项目构想与设计思路——工具和音乐为什么要放在同一个空间1.1 定位不是博客不是导航站是“属于我自己的空间”一开始我也纠结过这到底算什么是个人导航页是工具集合还是音乐播放器后来想明白了都不是。“我的极客空间”这个定位的关键词是“空间”它强调的不是某一种功能而是一种归属感。你可以把它理解成数字世界的书房进去就能干活桌上有顺手工具旁边有可以随手开的音乐不用到处找东西。它不需要面对大众只需要服务我自己的习惯。这个定位反映到设计上就是——“我熟悉它”比“别人觉得好看”更重要。比如我不需要注册登录、不需要社交分享、不需要文章评论这些在传统网站上默认存在的功能在我这里都是噪音。明确了定位之后所有界面上的东西都变得好判断了与“快速使用工具”和“沉浸听歌”无关的东西一律砍掉。主页大标题叫“我的极客空间”副标题写的是“Tools Music for focused work”一眼就告诉来访者这里有什么功能。1.2 信息架构左右分栏、一步直达的设计逻辑信息架构上我最后定的是上下结构上部是工具卡片区下部是音乐播放条左侧放一个窄导航。有人会问为什么不用当前流行的侧边栏大菜单、多级页面因为这里的核心诉求是“一步直达”和“同时可见”。工具类网站最讨厌的是什么点一个工具跳到新页面等加载完再用然后返回再点下一个。这种跳转感会直接打断工作节奏。所以我把所有工具都做成了卡片平铺在页面里点击即展开用完即收起全程没有页面跳转。工具区在上方因为这是高频需求音乐条固定在底部任何时候都能切歌、暂停不遮挡内容。导航只放四个锚点工具集、音乐台、关于、设置。都是单页面内的平滑滚动。整个页面本质上是一个单页应用SPA风格但没有任何框架依赖就是原生HTMLCSSJS加载飞快逻辑透明。我特意避免多级菜单因为当你的工具列表超过十个之后多级菜单只是把“找东西”这件事从滚动变成了点击并没有在效率上赢。1.3 场景倒推从使用频率出发而不是从想象力出发这里要说一个很关键的方法功能清单不是拍脑袋列出来的而是从真实使用场景倒推。我花了一个星期记录自己每天打开浏览器都在用什么统计结果是这样的开发与调试类JSON解析/格式化、正则表达式测试、时间戳转换、Base64编解码、URL编解码这些属于写代码时高频出现的操作。信息处理类二维码生成/解析、颜色值转换HEX/RGB/HSL、进制转换属于偶尔用但一旦用就很难找好的工具。文本与格式类字数统计、Markdown转HTML主要是写文档时用。音乐场景也拆成两类写代码的适合纯音乐/白噪音午休或者做一些机械操作时可以听带人声的歌曲。这两类在歌单里用标签区分播放条上有切换按钮。把场景和数据摆到一起你会发现功能优先级特别清晰先保证开发类工具的稳定性和响应速度再补信息处理类最后才考虑美化类功能。这个顺序颠倒不得因为一个工具如果没有做到“零思考使用”它的存在就没有意义。2. 技术选型把复杂度留在外面把简单留给用户2.1 为什么不用大而全的框架接下来是技术选型。很多人一听个人网站下意识就上Vue/React Node后端再做数据库甚至配上管理系统。我的判断完全不同这个项目我用纯前端静态方案连构建工具都没配。原因是复杂度要匹配场景。工具区虽然有十几个工具但每个工具本质上是“输入——处理——输出”的独立函数它们之间没有共享状态也不需要服务端存储音乐区也只需要一个播放器在前端控制音频文件本地音频直接通过静态目录引用。一个不需要鉴权、不需要数据库、没有用户间交互的项目引入前后端分离架构就是在给自己挖坑。静态方案带来的好处非常实际部署成本接近于零随便一个静态托管就能上线不需要维护服务器。打开快没有服务器端渲染延迟首屏只需要加载HTML、CSS、少量JS和字体。容易迁移。文件夹打包扔到任何静态托管甚至U盘拷走都能跑。当然我并不是说框架无用如果后续要加入用户上传工具配置那确实需要后端。但就目前这个需求纯前端是“用最小的复杂度解决当前问题”而不是“用最流行的技术做一个超出需求的东西”。2.2 工具模块把重复劳动留给组件工具区最大的技术难点不是某个工具的算法而是当工具数量增到十五六个之后怎么让代码不失控。我的方案是封装一个统一的工作台组件toolkit workspace每种工具是一个独立的渲染卡片拥有统一的输入区、触发按钮、输出区对外暴露一个process(input)方法。这样每种工具只需要关心自己的核心逻辑不用重复处理布局和交互。实际开发时我把工具抽象成三类对应三种交互形态普通转换型一个输入框、一个转换按钮、一个输出框。比如 Base64、时间戳、URL编解码。实时处理型一边输入一边出结果不需要按钮。比如字数统计、JSON格式化校验。生成型没有输入只有参数和输出。比如二维码生成、UUID生成。这三种形态在代码里对应三个不同的渲染函数但对外接口保持一致。这样做的直接好处是新增一个工具往往只需要写核心处理函数和配置一行描述信息剩下的交互代码全是复用。2.3 音乐模块一份JSON驱动整个歌单音乐模块的选型上我没有用任何现成的播放器插件直接基于浏览器原生audio元素封装。音频文件放在站内目录下歌单信息写在一个playlist.json里页面加载时通过fetch读取然后渲染列表。为什么不调用某个平台的开放API或者直接嵌入第三方播放器原因有三第一第三方播放器会有弹窗、推荐和排行榜这类干扰元素违背“专注空间”的初衷第二接口授权和访问限制不稳定哪天策略变了页面就废了第三本地文件可控我收集的音乐资源都是自己购买或者有版权的不存在服务方下架的问题。播放器核心状态其实只有几个当前索引、播放状态、当前时间、音量。这些都放在一个简单的播放器对象里管理。这里有一个小经验不要把播放进度绑定到DOM操作上而是绑定到timeupdate事件里去更新UI这样代码更清晰也不会因为DOM查询拖累性能。3. 核心功能实现与关键代码3.1 工具区落地实录高频工具的代码实现工具区我挑一个最有代表性的“JSON格式化校验”来讲因为它的实现最能体现“输入即反馈”的设计思路。这个工具的交互是用户在左侧粘贴一段JSON右侧实时显示格式化后的结果如果JSON有语法错误右侧直接标红并提示错误位置。全程不需要点击任何按钮。核心逻辑用到了JSON.parse配合递归格式化function formatJson(input) { try { const parsed JSON.parse(input); return { ok: true, text: JSON.stringify(parsed, null, 2) }; } catch (err) { const lineMatch err.message.match(/position (\d)/); let line -1; if (lineMatch) { const pos Number(lineMatch[1]); line input.substring(0, pos).split(\n).length; } return { ok: false, error: 第 ${line} 行附近语法错误: ${err.message} }; } }格式化用JSON.stringify(parsed, null, 2)本质上是一个深度优先遍历并补齐缩进的过程两格缩进是最通用的可读性选择。错误提示方面JSON.parse的报错信息里带position通过计算换行符数量可以定位到行号这对调试非常有用。另一个比较实用的例子是时间戳转换工具。这个工具需要同时处理秒级和毫秒级时间戳很多在线工具在这上面都翻过车。我的做法是通过位数判断十位数按秒处理十三位数按毫秒处理然后再给用户一个手动强制选择入口。function tsToDate(input) { const num Number(input); if (isNaN(num)) return { ok: false, error: 不是有效数字 }; const ms num 1e12 ? num : num * 1000; const d new Date(ms); return { ok: true, text: d.toLocaleString(zh-CN, { hour12: false }), detail: UTC: ${d.toISOString()} }; }这里1e12是一个经验阈值当前时间戳换算成毫秒大约在1.7e12任何小于1e12的数基本可以断定是秒级。这个策略在线工具里也非常常见但很多人没注意细节直接写死了秒级导致遇到毫秒级时间戳就出问题。下面是我的工具清单给计划做相同方向的朋友一个参考工具名核心能力实现要点JSON格式化/校验实时格式化与错误定位JSON.parse 递归stringify 行号定位正则表达式测试实时高亮匹配在textarea中动态创建匹配标记span时间戳转换秒/毫秒自适应、日期格式化位数判断 toLocaleStringBase64编解码文本/Unicode安全转换注意使用encodeURIComponent处理中文URL编解码组件级与整体转换decodeURIComponent 的异常捕获二维码生成文本/链接生成二维码引入qrcode.js时走本地CDN转存储UUID生成器批量生成、格式选项crypto.randomUUID 自定义模板颜色转换HEX/RGB/HSL互转分别解析通道并处理边界条件进制转换2/8/10/16进制互转手动实现防止大数精度丢失Markdown预览左侧编辑右侧渲染marked.js 本地化 防注入处理3.2 音乐区播放器三个关键交互的实现音乐区看似简单但播放器要做到“好用”有三个交互必须打磨到位。第一个是进度条拖拽。原生audio的currentTime可以直接赋值但拖拽过程中有个细节滑块移动时应该用拖拽位置去实时预览时间松手时才真正跳转。否则一边拖一边播放会导致声音和进度对不上体验非常撕裂。实现上我用mousedown开始拖拽mousemove更新预览mouseup提交跳转。第二个是键盘快捷键。做“极客空间”怎么能少了键盘操作我绑定的键位是空格播放/暂停、左右方向键快进快退、上下方向键调音量。这个设计借鉴了视频播放器的操作逻辑用起来很顺手。document.addEventListener(keydown, (e) { if (e.target.matches(input, textarea)) return; // 不干扰输入框 const audio player.audio; switch (e.code) { case Space: e.preventDefault(); player.toggle(); break; case ArrowRight: audio.currentTime Math.min(audio.duration, audio.currentTime 5); break; case ArrowLeft: audio.currentTime Math.max(0, audio.currentTime - 5); break; case ArrowUp: setVolume(Math.min(1, audio.volume 0.05)); break; case ArrowDown: setVolume(Math.max(0, audio.volume - 0.05)); break; } });这里最容易被忽略的是e.target.matches(input, textarea)判断。不加这句话你在工具区打字按空格音乐也会跟着暂停这是灾难性的体验。第三个是随机个绍。随机播放在很多播放器里是洗牌但我觉得更舒服的是“随机单曲循环”从当前歌单中随机选一播放播完后再从剩余曲目中随机选。这样既避免了洗牌模式下连着切歌的手忙脚乱又不会一直重复同一首。3.3 让“空间感”立起来的细节设计空间感听起来很虚但拆开其实是一些很具体的感知要素进去时感受到的欢迎感、停留时的视觉氛围、离开时的熟悉感。我在页面上加了三个小而暖的设计第一个首次访问时页面中央浮现一句“欢迎回到你的极客空间”渐隐后归于工具区第二次访问就不再显示只保留一个极小的问候语在左下角。第二个背景我做了一个不影响性能的Canvas微粒动效鼠标划过时颗粒会跟随但限制了这个动效只在宽屏且系统非省电模式下启用。第三个是夜间模式。对于经常半夜写代码的人来说一个亮得刺眼的页面是不可接受的。夜间模式我做了三档切换跟随系统、强制日间、强制夜间通过prefers-color-scheme监听和手动覆盖。配合CSS变量整个页面的颜色一档就能切完不需要写多套样式。一个重要的经验不要为了追求视觉炫技牺牲默认速度。粒子背景再好看如果加载时要卡一秒用户第一印象就毁了。所以我的实现方式是粒子背景默认是纯CSS渐变兜底Canvas脚本异步加载脚本没加载完成或者移动端低性能模式下自动降级为静态背景。4. 从本机到公网部署上线与日常迭代4.1 免费托管平台对比与选择网站本地跑通之后部署其实非常简单。我对比了三个免费静态托管GitHub Pages、Cloudflare Pages、Vercel。最终选的是Cloudflare Pages理由也很直接GitHub Pages虽然老牌但国内访问速度不稳定而且免费版的自定义域名无法直接启用HTTPS现在可以了但曾经有折腾成本。Vercel部署体验极好自动预览每个分支但对免费用户的带宽有一定限制而且“重型”项目偶尔会触发构建超时。Cloudflare Pages在国内的访问速度相对最稳自带CDN、自动HTTPS、每天免费构建次数足够个人项目用DNS托管也是同一家域名解析和CDN能一站配齐。部署流程基本上是Git仓库推送到远端在Cloudflare Pages创建项目选择仓库和构建输出目录我这里直接打空目录因为全是静态文件首次构建完成后就会拿到一个.pages.dev域名。自己的域名走过去上下两条CNAME记录就行一条根域、一条www子域都是指向 pages.dev 的地址。这里有个特别的细节如果你在Cloudflare托管域名DNS里直接选“CNAME代理”模式图标是橙色云朵这样解析记录会自动走Cloudflare的CDN访问速度和防护都更好。4.2 用Git管理内容和版本个人网站很容易犯的毛病是改着改着就乱了改完又后悔旧版已经没了。我全程用Git管理每个页面文件的改动都走提交大了说方便回滚小了说知道每版改了什么。只用一条命令记录就够了不搞复杂分支git init git add . git commit -m add core tool card and player layout音乐文件的版本管理有一点要特别声明音频文件体积比较大全塞进Git仓库会导致仓库越来越臃肿克隆和拉取都变慢。我建了一个.gitignore把音频目录排除在版本控制之外只提交playlist.json。本地音频文件夹通过同步盘单独备份这样仓库保持轻量音乐文件也不会因为误改而丢。音轨资源我储存的方式是从购买的无损源转码成320Kbps的MP3放本地再按时长和音质筛选出一份常听的约3GB。真要细究其实没必要全部放线上挑一个适合工作/专注的轻量列表放进网站目录就够了。4.3 迭代节奏与内容运营个人网站的维护有个常见误区一口气把所有想法都实现然后热情耗尽之后半年不更新。我的方法非常反着来——每次只加一个工具改完就上线更新频率固定每周一次。我做了一个“上线候选清单”表格里面分区记录想到的工具和歌曲每期从里面挑最简单的一个做。做完即部署“部署”这个动作的成本越低你就越愿意频繁优化。一个很直接的感悟一个不断有小改进的网站永远比一版功能塞满但要等两个月才能见面的网站更能给人满足感。至于统计我初期没有上任何统计服务因为“自己的空间”不太需要关心流量。后来为了确认页面在自己的设备上加载表现我在Cloudflare的日志里偶尔看看请求数和流量峰值。如果未来想在开放时观察访问趋势再引入极简的、无追踪器的计数脚本也不迟。5. 踩坑记录浏览器兼容、跨域与移动端适配问题排查5.1 自动播放被拦截是浏览器策略也是体验问题第一次做播放器的时候我想让用户一进页面就能听到音乐于是在页面加载后调用audio.play()。结果在Chrome和Safari上全都不工作控制台还报错。原因是现代浏览器都要求“用户手势”后才能播放有声媒体这是一条明确的安全策略。技术上确实有绕过的路子但我不建议也不需要使用那种方式去欺骗浏览器。而且从体验角度看用户刚进页面如果突然响起音乐第一反应大概率是慌慌张张找暂停键。所以现在的逻辑是页面里放一个显眼的“进入空间”按钮点击后才触发画面渐隐和音乐淡入。这样既有仪式感又完全符合浏览器策略。提示如果你确实想在页面加载后马上播放纯音乐或白噪音可以考虑在文档的visibilitychange事件里做第一次用户交互后的自动播放但依然要处理好取消静音时的用户手势问题。5.2 本地直接打开HTML时音频集体失效开发时我用file://协议直接双击打开index.html音频全部加载不出来报跨域错误。具体原因是浏览器安全策略限制页面通过file://打开时fetch请求本地JSON和音频会被拦截看不到的是它把每个本地文件当成了独立的源。解决方式很简单起一个本地静态服务器。Windows和macOS上都写一行# 在项目根目录执行 python3 -m http.server 8080然后访问http://localhost:8080所有fetch和音频请求都走HTTP协议跨域问题立刻消失。后来我把这行命令写进了项目的README当作启动说明第一条。反正个人项目没必要引入复杂的本地构建流程。说个更隐蔽的坑页面部署后音频路径要用相对路径还是绝对路径我建议全部用相对路径例如./media/songs/001.mp3。这样整个文件夹无论放到域名根目录、子目录还是本地服务器都能正常工作。如果你写了类似/media/001.mp3的以根开头的路径部署到子目录时就会全部404。5.3 移动端适配与性能的几个取舍虽然这个网站主要给自己电脑上用但总有躺床上拿平板和手机刷的时候。移动端适配我踩了两个坑一个布局一个性能。布局上一开始的工具区是五列卡片到了手机上就挤成一团卡片里的输入框窄得没法用。后来用CSS Grid改了断点.tool-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: 16px; }minmax(280px, 1fr)的含义是每张卡片最小宽度280像素当容器空间不足时自动换行空间富余时均分。这套响应式方案的好处是不用写具体的媒体查询完全由容器宽度推导列数适配任何屏幕。性能上十五个工具如果全部加载JS和依赖移动端初访会比较吃力。所以我把工具的依赖脚本改成按需加载卡片初次展开时才用动态import()拉取对应脚本平时只加载核心代码。简单算一下首屏体积从大约900KB降到了约300KB移动端上打开快了不少。用户初次访问如果感觉“秒开”体验分就稳了。5.4 常见问题速查表现象可能原因解决办法音频无法播放浏览器自动播放策略拦截改为用户点击后触发播放或在首次触摸事件中调用play()本地打开页面后工具报错file://协议下fetch被拦截使用python3 -m http.server 8080启动本地服务部署后图片/音频404使用了以 / 开头的绝对路径全部改成相对路径./xxx或为页面设置base路径手机页面卡片太挤固定列数布局使用auto-fill minmax的Grid网格布局按空格键导致工具输入中断全局键盘事件没排除输入框在事件回调中先判断e.target.matches(input, textarea)粒子动画让风扇狂转动画常驻且无性能控制设为异步加载低性能设备自动降级静态背景时间戳转换结果差8小时直接使用了UTC小时未加时区偏移使用toLocaleString或getTimezoneOffset处理最后再分享一个实际使用中的小体会。这个站点现在每天都会被我打开它其实不酷炫代码也没什么高深魔法但那种“工具和音乐都在一处随处可用”的感觉比很多重型产品都顺手。如果你也想做类似的东西我的建议是第一版不要追求多少工具多少歌曲先把你每天必用的三个小功能和一个常听的播放列表做成一个页面放在公网上然后坚持每周加一点。坚持三个月后回头对比你会看到这个“空间”真的在跟着你的习惯一起生长。