开发的那些常用网站一份我用了几年还在用的清单前阵子做一个小型演示项目客户端环境断得一干二净没有本地数据库、没装任何深度依赖甚至连 IDE 的组件缓存都清了。我打开浏览器依次登了三个网站——一个查配置、一个写测试接口、一个在线跑前端代码前后不到十分钟就把功能验证完了。旁边的同事很惊讶“你居然不靠公司搭的环境也能干活”我说不是我不靠环境而是开发这事儿真正高频依赖的从来不是某个庞大的一体化平台而是那些已经被工作流验证过无数次的小众/大众网站工具。这篇文章不是要把互联网上所有开发网站搬到收藏夹而是把我平时真正打开频率最高的网站按学习、编码、联调、交付这几个实际场景梳理一遍。适合刚入行想找信息入口的新人也适合觉得自己收藏夹很满但每次开工还是无从下手的全栈、前端、后端开发。看完你能把“网站资源”从收藏夹式的堆积变成按需取用的工具箱。1. 别让收藏夹变成垃圾场开发网站资源分层的思路收藏夹里塞几百个链接并不会有任何生产力。真正的问题不在“链接不够多”而在“没有一个分层逻辑”。我早期也走过这个弯路GitHub Trending、各种工具合集、教程贴每天刷完就存真到写代码的时候还是搜索引擎从一个页面跳到另一个页面非常耗神。后来我把资源按使用频率和使用场景分成了三层这个习惯一直沿用到现在。1.1 三层分类法高频、中频、低频高频几乎每个工作日上午都会打开。比如文档站、代码托管平台、接口调试工具、在线代码片段平台。这里面的工具一定要选可靠、长期维护的项目否则你花了大量精力养成习惯之后它突然不维护了换血成本很高。中频一个迭代周期用几次比如性能检测站点、测试环境管理面板、代码覆盖率报告页面。低频偶尔需要才用比如图表生成器、二维码生成、时间戳换算、静态图标仓库。低频工具的特点是“用的时候特别急”所以要建立一种“搜得到”的能力而不仅仅是收藏。按这个逻辑我很少专门去收藏“XX个开发者必备网站合集”这类文章因为合集通常只按首字母排序没有场景化。我更愿意自己维护一份短清单每个月花十分钟更新一次。1.2 按工作流而不是按网站名气来分配入口一个典型的开发流程可以压缩成四段学习和调研、编码和调试、联调和交付、运行和维护。每个阶段我都会选定一个“主入口”。学习和调研搜索引擎 官方文档 代码问答社区。编码和调试代码编辑器 在线运行环境 调试代理工具。联调和交付接口管理平台 代码托管平台 持续集成页面。运行和维护监控面板 日志平台 告警通知。这四个阶段需要的网站往往没有重叠。如果我只告诉你“要用 GitHub”却不说它落在哪个阶段那对实际工作的影响就很有限。这篇博文后面几个章节就按这条路径展开你可以按自己的岗位和阶段对号入座。1.3 一个反直觉的建议主动关注“文档站”而不是“导航站”很多导航站把各种工具铺在一个页面上看起来琳琅满目。但真正进入工作状态后你需要的不是看到一个工具的名字而是看到它的文档。比如我今天要写一个处理数组的分组逻辑我不会先打开导航站找“有哪些数组工具库”而是直接打开 MDN 查reduce、groupBy的语法。所以在我心里一个稳定、准确的文档站价值远高于一个工具聚合导航站。2. 学与查的入口站文档、搜索、算法平台的正确打开方式这一章节聊的是“遇到不会的问题时去哪里查”。很多开发新手喜欢问人或者看随机博客这种方式不能说没用但效率很低。因为这时代的核心不是“找答案”而是“找权威答案 验证答案适用版本”。2.1 MDN 与官方文档永远的第一站前端开发者对 MDN 应该都不陌生。我把它称为“网页开发的词典”。它的价值在于不只告诉你一个 API 是干嘛的还会给你兼容性表格、示例代码、使用备注。比如你想知道Array.prototype.at()支持哪些浏览器直接翻 MDN 的兼容性数据就行比看一堆过时教程要靠谱得多。后端和客户端方向同理Spring 有官方参考文档Python 有官方库文档Kubernetes 有概念与任务页面。我的习惯是先打开官方文档搜一遍搜不到再去社区搜索这个顺序能避免踩到大量陈旧信息的坑。2.2 Stack Overflow提问少见搜索常见Stack Overflow 是全球最大的开发者问答社区。说句实话我自己很少在上面提问因为大部分问题早都有人问过了。我是把它当“大型 bug 字典”来用的。要想用好它有几个搜索技巧搜索时带上语言、框架版本和操作系统。比如直接搜redis connection timeout太泛了换成stackoverflow redis connection timeout node.js能精准不少。优先看答案数量多且“已接受答案”标记的问题。通常社区已经替你筛选过一轮靠谱结论。注意问题发布年份。2018 年以前的问答很多 API 用法现在已经变了复制代码前要对照版本差异。同样的逻辑也可以用在 GitHub Issues 里。有些框架的坑官方文档没写Issues 里却有一线开发者踩过。我会在搜索引擎里加一句site:github.com/xxx/xxx/issues能搜出非常具体的历史问题讨论。2.3 算法和面试题平台力扣与 LeetCode 的路线差异算法题平台很多我长期用的是 LeetCode 和国内的力扣。两者题库相同但国内版的中文翻译、每日一题和会员服务更贴近这边的工作节奏。刷题的价值当然不只是面试。我在做一些数据结构和状态转移相关的功能时常常会回想刷过的题目它们会直接影响我选择什么遍历方式、怎么建索引。不过对于算法学习我建议不要只刷题。可以配合可视化站点把排序、二叉树、图遍历过程“看出来”比读代码更快。这类可视化网站很多随便搜就有关键是别收藏太多留一两个顺手的长期用。2.4 随手沉淀笔记不要让收藏夹承载记忆网上资源再多不经过自己整理遇到问题还是得现搜。我现在的做法是每周找 30 分钟把周内排查过的疑难问题写成简单的“问题-原因-解决”笔记放到自己的知识库里。笔记站点可以选语雀、Notion、思源笔记甚至 Markdown 文件Git 仓库都行。关键是用自己的话重写一遍不要直接剪贴原文。不要小看这个动作它能把“熟悉的陌生人”变成真正能调用的知识。3. 编码和联调期间我几乎每天都会开的在线工具写代码才是开发工作的重头戏。这里说的“编码和联调”不单指编辑器也包括那些在电脑上没法独立完成的临时需求——比如快速验证一段脚本、构造一条接口数据、抓一个移动端请求。下面这几类网站和工具是我实测下来效率提升非常明显的一批。3.1 在线代码片段CodePen 不只是前端玩具很多人提到 CodePen第一反应是“前端炫技的地方”。其实它的核心价值是零成本搭建一段可运行的前端代码。我经常用它做两件事从 Stack Overflow 或其他地方看到一段 CSS/JS 效果想弄清楚它怎么工作把它粘到 CodePen 里跑一下拆开看每一行影响什么。给同事或客户演示一个问题把最小复现代码扔到 CodePen/CodeSandbox对方打开链接就能看到效果不用下载项目、跑依赖。如果是需要完整依赖的 React/Vue 项目用 StackBlitz 这类在线 IDE 会更合适。它能在浏览器里启动一个完整开发环境甚至支持安装 npm 依赖对快速验证开源库、给开源项目提 Issue 的复现场景非常有用。这些在线工具的共同点是它们把“环境搭建”的时间压缩到了零对于需要快速验证想法的场景价值不可替代。3.2 接口调试Postman、Apifox 怎么选接口调试是前后端开发都要做的事。前几年 Postman 基本是标准答案它功能全、云端同步、支持环境变量和自动化测试。后来国内越来越多的团队开始用 Apifox因为它在 Postman 的功能基础上内置了接口文档、Mock 数据和团队协作整体体验更符合国内团队习惯。我经常用下面这张表的维度给团队推荐对比点PostmanApifox界面/文档全英文为主界面成熟中文优先更贴近国内使用习惯接口文档生成需要额外配置或第三方工具内置自动生成 API 文档Mock 能力需要手动配置 Mock Server内置根据接口定义生成 Mock 数据团队协作云端团队工作区项目级权限管理成员协作更轻适合场景国际化、跨团队、习惯海外工具链国内中小团队、前后端联调频繁说实话没有绝对的“最好”关键是选一个团队主力工具然后把接口定义、环境变量都沉淀在里面。我自己现在更偏向 Apifox因为它把“接口文档-测试- Mock”串成了一条线省了在多个工具之间切换的时间。3.3 抓包和代理有些问题只在浏览器控制台之外我们在本地开发时偶尔会遇到“明明后端说返回了前端就是拿不到数据”的情况。这时候用浏览器控制台看 Network 面板是一个方法但遇到 App 内嵌页面、小程序页面或者命令行接口时控制台就不够了。我会在电脑上装一套代理抓包工具比如 whistle 或 Charles。它们做的事情本质上就是把手机或客户端的请求转发到代理服务器然后在电脑上看完整请求/响应内容甚至直接把一个线上地址指向本地服务。这样调试线上样式问题、线上环境数据问题非常方便。这类工具的学习曲线其实不陡花半小时看一遍官方快速开始就能上手收益却能伴随整个职业生涯。关键是需要调试跨端场景时别在浏览器控制台里死磕换一个能看完整数据链路的工具往往一击即中。3.4 那些小而美的“工具页”JSON 格式化、正则、时间戳我使用频率最高的工具反而不是那些大型平台而是几个长得特别朴素的小站点JSON 格式化/校验前后端联调时接口返回一长串 JSON直接扔到格式化器里展开层级关系一目了然。推荐 json.cn 或 bejson。正则表达式调试写正则不能靠猜。我会在支持实时匹配的测式站点上一边写一边看结果避免在代码里来回试错。时间戳/日期换算接口层经常遇到毫秒级时间戳随手查一下换算结果比自己在代码里写一段调试输出快很多。代码 Diff 对比两段文本/代码比对有些小工具可以直接贴文本看差异适合排查配置文件被谁改动过。这类站点普遍的特点是打开快、页面简、直接解决问题。我通常不会把它们放进收藏夹而是靠搜索关键词随时调用。因为站点太多了记不住也没关系只要你知道“这类问题可以当场搜索工具解决”就够了。4. AI 编程时代我每天必开的后台与提示技巧这两年 AI 编程工具快速普及我的习惯也跟着变了。过去我高频打开的是文档和社区现在每天至少还有两个 AI 工具入口一个是编辑器里的代码补全助手一个是能够处理长上下文的大模型对话页面。它们解决的是不同问题辅助效果差异很大。4.1 分清“补全工具”和“对话工具”编辑器内 AI 补全比如常见的 Copilot 系插件、通义灵码、Codeium 等。它们的强项是“在你写代码的过程中给出下一步建议”适合处理样板代码、模式化函数、单元测试生成等。这种工具要养成“看一眼再接受”的习惯不能全盘照收。通用大模型对话页面比如各类国内外的 AI 对话产品。它们的强项是处理“整块问题”给一段报错信息让我定位原因把一段逻辑用另一种语言实现或者解释一个开源项目的架构。我把它们当成“懂很多东西的结对同事”可以和它反复讨论方案但最终决定权在我。我在实际工作中的分工是敲代码时靠编辑器补全加速遇到不熟悉的库或晦涩报错时打开对话工具把报错帖进去让它给排查路径。这样“工具型 AI”和“知识型 AI”各就各位效率才最高。4.2 一个能明显提升准确率的提示框架很多朋友说 AI 给的代码“看起来对跑起来错”。我试过之后发现大部分时候不是 AI 能力不够而是提问太模糊。我自己常用的提示框架很简单就四步背景先说我用的是什么语言、什么框架、什么版本。目标我要实现的最终效果是什么不要只说一句话把输入输出说清楚。约束比如不支持旧语法、需要兼容某浏览器版本、性能要求是千条数据不卡顿。输出格式希望它给完整方法还是给修改后的某段代码。举个例子如果我想让 AI 帮我写一个前端分组函数我大概会这么写背景项目是 Vue 3 TypeScript使用 lodash-es。目标把一个对象数组按属性 groupId 分组并返回 Recordstring, Array 。约束不允许直接修改原数组空数组也返回空对象。输出格式给出完整函数 一个简单用法示例。这样问出来的答案可用性高很多。这个方法也可以反向用在排查问题上贴报错时附带相关代码片段和输入数据比只贴一行报错信息靠谱得多。4.3 AI 辅助的边界什么代码不能直接交给 AIAI 工具虽然是好助手但有两个地方必须人工把关。安全与敏感信息绝对不要把数据库连接串、云厂商密钥、客户个人数据贴到公网对话工具里。这些内容一旦进入外部服务就可能造成数据泄露。正确做法是先把敏感信息替换成占位符再放进提示词里。依赖和 API 的时效性大型语言模型的训练数据有截止时间它对最新版本库的 API 了解不一定准确。前一阵 AI 给我推荐了一个写 PDF 的库我照着写完了才发现那个库已经两年没维护函数签名早变了。所以凡涉及第三方库我都会先去官方文档确认版本和 API再决定是否采用。AI 时代的开发能力更多体现在“怎么把需求拆清楚”和“怎么验证答案对不对”而不是“会不会背 API”。这也是我现在带团队时反复强调的一点。5. 前端和素材资源站后端也能快速搞定视觉问题后端起家的开发者最头疼的往往不是接口而是页面“一眼假”。其实借助几个专门的资源网站后端起家的开发者也能在半小时内搞定一幅过得去的界面。这里分享几个我收藏夹里久经考验的资源站分类。5.1 图标库比一张张切图省事得多页面只要涉及按钮、菜单、状态提示就一定需要图标。我的首选是这三类iconfont国内团队常用图标丰富且能按项目生成字体文件支持自定义色彩。Font Awesome最经典的字体图标库引入一个 CSS 文件就能用全套图标。Feather Icons风格简约线条统一适合做工具类网站。用法上需要注意的是不要在一个页面上同时混用多个图标库视觉风格会很不统一。选定一套保持全站一致比“哪个图标好看用哪个”更重要。5.2 配色和阴影生成器设计感和从零硬写的差距颜色搭配是开发者的传统弱项。我很少自己硬想色值而是直接用配色工具。比如 Coolors 可以快速生成一个协调的调色板CSS Gradient 和 uiGradients 能直接复制好看的渐变背景代码。还有一个隐藏技巧是在配色工具的辅助下选完主色后用对比度检查工具算一下前景色和背景色的对比度保证文字可读性。可读性不达标的配色再好看也会被用户立即吐槽。5.3 图片压缩与字体加载性能优化从源头上解决问题一个页面如果图片体积占了几百 KB再好的性能优化方案也只是亡羊补牢。我在发布前会习惯性地用在线压缩工具处理一遍设计稿素材。TinyPNG 和 Squoosh 都很好用前者压缩 PNG/JPG 效果好后者支持更多格式和参数调整。字体方面尽量不要直接引一个几 MB 的完整字体文件。只需要确认你用的自定义字体格式是否支持font-display: swap再按需加载子集就能让首屏文字显著变快。这些资源站看起来很小但对用户体验的影响非常大。6. 从开发机到生产环境部署、监控、自动化的常用站点代码写完之后还有最后一公里——把它跑起来并且保证线上可用。这一环里也有很多网站/平台必不可少只是它们不像写代码那样“每天高频”往往是在发版、观察告警时集中打开。6.1 静态站托管让前端项目一键全球上线现在的前端项目如果是纯静态站点或构建后产物直接部署到托管平台会特别省事。Vercel 和 Netlify 是我用得最多的两个平台它们的共同特点是关联 Git 仓库后每次 push 代码都会自动构建和发布并且自动分配 HTTPS 域名还支持环境变量、预览分支等功能。配合自己的域名管理也很简单不用自己搭 Nginx。对比点VercelNetlify适合项目Next.js 等偏框架/边缘函数静态站、JAMStack 综合能力构建设置默认配置聪明场景聚焦配置项细、插件生态丰富表单/Serverless能力偏弱内置表单处理和函数更成熟学习成本很低较低当然如果团队已经有比较成熟的云平台直接用云服务器配合 Nginx 或容器部署也行。重点不在于“哪个平台天下第一”而在于“建立一条从代码到线上的稳定流水线”让发版成为一种低风险动作。6.2 监控和日志上线只是开始线上不出问题是理想状态现实是总会出问题。监控类的网站和工具能帮你在用户骂人之前发现问题。我推荐至少配两道防线错误监控Sentry 是其中很典型的一个平台接入后能自动收集前端 JS 异常、后端崩溃并按错误次数聚合。你可以设置告警规则当某类错误超过阈值时通知到 IM/邮件。性能监控Lighthouse 和 PageSpeed Insights 都能对页面做性能诊断给出具体优化建议。它们适合用在发布前检查和大版本上线后的抽查。不要等用户反馈“页面卡死了”才去排查。把异常监控平台当成线上应用的“体检中心”每周花点时间看看趋势很多潜在事故都能提前消化掉。6.3 CI/CD 页面这个按钮按下去的瞬间持续集成/持续部署是现代开发的关键环节。我在代码托管平台的 Actions/Tasks 页面看流水线记录的时间往往比看编辑器还多。配置好构建、测试、部署流水线之后每天 push 代码就等于走一遍自动检查很多低级错误在合并之前就会被拦截。对于个人项目GitHub Actions 免费配额基本够用对于公司项目Jenkins、GitLab CI 或者云厂商的流水线服务都很常见。这类平台的特点是配置一次长期受益。虽然初次配置会花一些时间但之后每一次发版都能享受到自动化带来的安全感。7. 多年攒下来我的网站选择经验谈网站和工具更新迭代太快与其追着新工具跑不如建立自己的筛选和使用原则。收个尾分享几条踩过坑之后总结出的习惯。第一工具贵精不贵多。某个领域选 1-2 个主力就够。我曾经一天之内把接口调试工具从 Postman 换成 Apifox 又试了 Insomnia来回导入导出数据浪费了两个小时。后来想明白了工具是服务于工作流的不是用来“体验”的。选定一个长期用比反复横跳效率高得多。第二用搜索能力代替收藏能力。收藏夹只是资源的“堆”搜索能力才是资源的“取”。我现在的原则是凡是 5 分钟之内能搜到答案的一概不收藏。真正值得收藏的只有两类一是极少能被检索到的内部工具地址二是需要反复阅读的长文档。其余的都交给搜索引擎和书签工具的关键词。第三把好工具介绍给团队也是提升自己效率的事。同一个项目里你用 Apifox 做接口测试、同事用 Postman、另一个人直接在浏览器里打 URL协作成本会非常明显。与其自己默默用不如把“为什么选它”讲清楚推动团队统一工具链。统一之后环境变量、接口定义、Mock 数据共享起来整个团队都会更快。第四每半年清理一次收藏夹和本地工具。我发现很多网站半年后要么被收购改名要么功能已经被集成到更大的平台里。定期清理看起来是杂务其实是对自己工作流的一次复盘——顺手丢掉那些已经不需要的留下的就是你真正的生产力入口。开发工作没有一个“必背清单”但好的网站和工具确实能让日常工作少走很多弯路。希望这份按场景整理的清单能给你一些参考。如果你也有那种常年放在浏览器书签栏第一位、屡试不爽的网站欢迎在评论区补充分享。
