dev.to 投稿指南：怎么发文章才有人看，外链顺带拿到

dev.to 是什么

dev.to（域名 https://dev.to）是 Forem 公司做的一个开发者社区，DR 90。说白了就是一个"开发者版的 Medium"——任何人都能注册、发文章、加 tag、被人 react / comment。

读者基本全是开发者。前端、后端、DevOps、AI 工程师都有。话题从 React hooks 到 Postgres 调优到 vibe coding，覆盖面挺宽。

发布免费，不用审核，注册完就能发。但不审核不代表随便发——社区有自己的口味，营销味重的帖子掉 reaction 掉得很快，发了也是没人看。

跟 Medium 不一样的几点，先记住：

• 开发者读者占绝对多数，给非技术内容点赞的人很少。
• Markdown 原生支持，代码块、liquid tag 嵌入 CodePen / GitHub Gist 都能做。
• 没有付费墙，作者也拿不到分成。这里的回报是关注、外链、和文章长期 SEO。
• 有个 canonical_url 字段，专门给跨发用——这玩意儿是 dev.to 最值钱的功能。

还该往这里发吗

要分情况看。

值得花时间发的：

• 你做产品的过程中踩了具体的坑，写出来对别的开发者有用。比如"用 Cloudflare Workers 部署 Next.js 时 D1 binding 这块的坑"。
• 你的产品本身是给开发者用的（API、SDK、CLI、开源工具）。读者就是潜在用户。
• 你想给自己/产品做点品牌内容，长期还能吃到 Google 搜索流量。
• 你已经在自己博客上写了文章，想顺手二发拿曝光。

别投的：

• B2B SaaS 卖给非开发者的（HR 系统、销售工具）。读者维度对不上。
• 纯产品发布稿。dev.to 不是 Product Hunt，发"我们今天发布了 X"会被冷处理。
• AI 工具堆砌 listicle、"10 个最好的 X"——这种营销文社区会反感。
• 翻译稿、AI 生成稿不改一笔。一眼看出来，掉信誉。

老实说，对大多数 indie hacker 和给开发者卖东西的小团队，dev.to 是性价比挺高的渠道之一。但前提是你愿意花时间写一篇真东西。

dev.to 在按什么排序

dev.to 首页有几个 feed：Latest（按时间）、Top（按时段内 reaction）、Relevant（个性化推荐）。要被更多人看到，主要看几件事：

• 早期 reaction 数量。文章发出后 1-2 小时内拿到几个 ❤️ / 🦄 / 🔖，会被推到 Relevant feed 上。冷启动几个小时没人理，基本就埋了。
• tag 选得对不对。每篇最多 4 个 tag，tag 跟内容不匹配会被社区折叠或者举报。
• 标题清楚。"How I cut my Postgres query from 2s to 80ms" 比 "Optimizing my database" 强一个量级。
• 配图有没有。cover image 不是必须的，但 feed 里没图的帖子点击率明显低。
• 作者历史。新号发第一篇没人脉冷启动很慢。先去给别人留几条有内容的评论再发。

最常见的翻车点：把发布稿当文章发。"Introducing X, the future of Y" 这种标题——开发者读者训练有素，看到立刻划走。

发布前要准备什么

还有两周

挑一个具体的话题。不要"我做了 X 这个产品"，要"我用 X 解决了 Y 这个具体问题"。把话题拆细到一篇文章能讲完的颗粒度。

去 dev.to 上搜你的话题关键词，看排在前面的文章长什么样。模仿结构，不抄内容。一般 1500-3000 词的实操类内容回报最好。

还有一周

写正文。Markdown 写。代码块用三个反引号加语言名（```js、```python）。截图压到 200KB 以内，dev.to 自己有图床但加载慢。

挑 4 个 tag。第一个 tag 优先级最高，建议是话题最大类（#webdev、#javascript、#python、#ai 这种），后面三个再细分。

准备一张 cover image，1000×420 像素。dev.to 默认会按这个比例裁，发别的尺寸会被切。可以用 Canva、Figma、或者直接拿截图上面贴标题。

发布当天

挑发布时间。北美时间早上 8-10 点是 dev.to 流量最高的时段。如果你目标读者主要在亚洲，下午 8 点（北京时间）也能跑——日本、印度、东南亚的开发者这时候还在线。

发出去之后别只发完就走——前两小时盯着评论区，有人留言尽量回。早期互动直接影响算法推不推。

发布流程

第一步：注册并填好 profile

地址 https://dev.to/enter。可以用 GitHub / Apple / Google / Forem 账号登录。建议直接用 GitHub——profile 上会自动显示你的 GitHub 链接，社区识别度更高。

profile 一定要填齐：头像、bio（一句话讲你是谁、做什么）、Website 链接（这里挂你自己网站，rel 是 nofollow 但带流量）、Location、Skills 之类的。空白 profile 写文章没人会点关注。

第二步：写文章

点右上角 Write a Post。编辑器是 Markdown。最上面是 frontmatter（YAML），用来填标题、tag、cover、canonical_url 这种元数据：

---
title: How I cut my Postgres query from 2s to 80ms
published: true
tags: postgres, performance, webdev, backend
cover_image: https://example.com/cover.png
canonical_url: https://yourblog.com/postgres-perf
---

正文随便写，Markdown 全支持。dev.to 还有 liquid tag——{% github user/repo %}、{% codepen url %}、{% youtube id %} 都能直接嵌入。

写的时候记一条原则：写人话，写细节，写过程。"我尝试了 A，没成；又试了 B，发现 C；最后用 D 解决"——这种叙事比"5 Tips for Postgres Performance"列表强得多。

第二步半：用 canonical_url（重要）

如果你这篇文章会同时发在自己博客上、或者已经在自己博客上发过了，一定要填 canonical_url。指向你自己博客上那篇文章的完整 URL。

这件事的意义下一节专门讲，先记住：填了，搜索引擎认你自己博客是原文；不填，dev.to 会盖过你自己网站的排名。

第三步：发布并互动

点 Publish。文章会立刻出现在 feed 里。

发完之后：

• 把链接转到你自己 Twitter / LinkedIn / 公司群，给文章导一波种子流量。
• 文章发出去 1 小时内回到 dev.to，看有没有评论，有就回。
• 找 1-2 篇相关话题的别人文章，认真留个评论。系统会把活跃用户推到更多人面前。

第四步：持续

dev.to 不是发完就结束。一个月后回来看 dashboard，看看哪篇 reaction 最多、views 最多。把高表现的话题再写一篇深的，或者拆成 series。

canonical_url 怎么用对

这个事单独拎出来讲，因为是 dev.to 上最容易做错也最关键的一步。

为什么重要。 Google 看到两个 URL 内容一样，会自己挑一个当"原版"，把权重给那个 URL。dev.to DR 90，你自己博客如果只有 DR 5，Google 几乎一定挑 dev.to 的那一篇。结果就是你自己网站的文章被压根搜不到，外链权重全跑到 dev.to 上去。

canonical_url 怎么解决这个问题。 在 dev.to 文章 frontmatter 里写 canonical_url: https://yourblog.com/post-slug，dev.to 会在 HTML 里加一个 <link rel="canonical" href="...">，告诉 Google "我不是原版，那个才是"。Google 就会把权重判给你自己博客。

操作有三种打法，看你目标：

1. 博客先发，dev.to 后发。 这是最常见也最稳的玩法。先把文章发自己博客（让 Google 先索引几天），再发 dev.to 并填 canonical_url。结果是：自己博客拿主排名，dev.to 拿曝光和社区互动。
2. dev.to 先发，博客后发。 不填 canonical_url，让 dev.to 当原版。适合自己博客 DR 还很低、文章你不指望它给主站排名的情况。
3. 只发 dev.to。 如果你压根没自己博客，那就直接发，不用纠结。dev.to 会成为这篇内容的 Google 排名页面。

别犯的错：

• 两边都发但不填 canonical_url。Google 直接判 dev.to 是原版，你博客那篇白发了。
• 填错地址。canonical_url 必须是已经发布、Google 能爬到的页面，填一个 404 或者 noindex 的页面没用。
• 想"两边都拿排名"。这是不可能的，Google 只会挑一个。要么你博客赢，要么 dev.to 赢，二选一。

老实说，对绝大多数 indie hacker，博客先发 + dev.to 二发 + 填 canonical 是最优解。两边的好处都拿到。

怎么真的从 dev.to 拿到流量和外链

dev.to 上正文里链外站默认 nofollow（包括你 profile 的 Website 字段），所以不要把 dev.to 当纯外链工厂。它的真实价值在三个地方：

第一，文章 URL 本身在 Google 排名。 dev.to 的文章在 Google 长期能拿到流量。一篇好文章发完一年还在每月给你带几百几千次曝光。

第二，profile 页给你导流。 Profile 页有你的网站链接、GitHub、Twitter。文章下面 footer 也会贴你的简介。读者看完文章想了解你，会点过去。这部分流量虽然小但精准。

第三，社区放大效应。 一篇文章 reaction 上千的话，会被 dev.to 官号转发，被 newsletter 收录，外站（Hacker News、Reddit、Twitter）有可能转。这种二次扩散带来的真外链才是真正的回报——但前提是你那篇内容站得住脚。

具体打法：

• 每两周写一篇深一点的实操。比堆 5 篇水文有用得多。
• 把文章组成 series。dev.to 有 series 功能，把相关话题挂在一起，读者读完一篇会顺手翻另一篇。
• bio 里挂你的产品。一句话，不要广告腔："Building [产品名] for [人群]" 就够。
• 跟其他作者真互动。在你领域里活跃 5-10 个常发文的作者，定期给他们点 reaction 加评论，半年下来你的能见度比闷头自发要高很多。

发完之后做什么

文章发出来不是终点，是一个内容资产的起点。

把链接转到 Hacker News（用 Show HN 格式）、Reddit 相关 sub（r/webdev、r/programming、r/SideProject）、Twitter。能给前几小时再加把火。注意 Reddit 各 sub 规则不同，先看 sidebar。

文章数据稳了之后（一周左右），把它写进自己博客的"As featured in"区，或者作为外部内容证明放进产品 landing page。dev.to 链接 + 几百 reaction 是一种社交证明。

如果一篇文章效果特别好（top 7 days 之类的），把它扩展成视频、推文 thread、newsletter 专题。一个内容点至少出三种形式。

最后，把 dev.to 当固定栏目。每月稳定发 2-3 篇，半年后你会发现自己有了几千关注者、profile 流量稳定、几篇文章在 Google 长期排名。这种复利只有持续输出才能拿到。

常见翻车点

• 标题写"Introducing X"。这是产品发布稿格式，dev.to 读者不吃。
• 全文夸自己产品。开发者社区对硬广特别敏感，三段以后没人看。
• tag 乱选。#javascript 一个 tag 就能涨流量，但乱写 4 个不相关的反而被折叠。
• 不填 canonical_url 还两边发。前面讲过，自己博客直接被 dev.to 盖排名。
• 用 AI 生成内容不改。dev.to 用户对 AI 文风识别度极高，看两段就划走。
• 一发就走。前两小时不互动，文章基本就埋了。
• 评论区出现别人质疑你的产品就硬刚。开发者社区看的就是你怎么处理质疑，态度比对错重要。

dev.to vs Medium vs Hashnode

对开发者写技术内容的人来说：dev.to 社区更活跃，Medium 流量更大但读者更杂，Hashnode 适合直接当主博客（因为可以绑自己域名 + canonical 自动指自己）。三者不是替代关系，资源够的话三个一起发，主站点都填自己博客的 canonical。

常见问题

dev.to 收费吗？ 不收。注册、发文、所有功能都免费。dev.to 自己靠企业赞助和 Forem 这个开源项目维持。

多久会有反应？ 发文后 1-2 小时是关键期。如果 2 小时内 reaction 个位数，基本就埋了。第二天回来看数据基本能定型。

可以发已经在别处发过的文章吗？ 可以，强烈推荐顺手二发。但要填 canonical_url 指向原文，否则你自己网站会被 dev.to 盖排名。

dev.to 给的链接是 dofollow 吗？ 正文里链外站默认 nofollow，profile 上的 Website 链接也是 nofollow。不要把 dev.to 当纯外链工厂。它真正的价值是文章本身在 Google 排名 + profile 导流。

没人看怎么办？ 检查三件事：tag 是不是选对了、标题是不是太营销、cover image 有没有。还不行就去给别人多评论几次，混脸熟。新号没人脉冷启动是常态。

可以发自己产品发布稿吗？ 不建议。但可以写"做这个产品过程中踩的坑"——同样的产品但角度变成技术叙事，读者就接受了。

一周该发几篇？ 不强求频率。两周一篇深的远好过一周三篇水的。dev.to 算法对低质量批量发反而扣分。

同期可以一起打的其他平台

dev.to 是开发者内容渠道里很好用的一个，但不是唯一。下面这些可以组合着打：

• Hashnode：DR 83，开发者博客平台，可以绑自己域名。dev.to 二发完顺手再发一份。
• Medium：DR 94，读者更广。如果你的话题不是纯技术（比如 indie hacking、产品思考），Medium 反而比 dev.to 反馈好。
• Hacker News：DR 44，发出去后第一波导流就发 HN，能上首页一篇文章流量直接翻 10 倍。
• Indie Hackers：做 indie 项目相关的内容很合适，社区氛围比 dev.to 更聚焦在产品。
• CodeProject：DR 90，老牌开发者社区，话题偏后端、企业级。
• Substack：DR 93，如果你想做长期 newsletter，Substack 是主战场，dev.to 当二发渠道。
• Product Hunt：DR 75，产品发布的硬通货。dev.to 写技术博客做长期 SEO，Product Hunt 做发布日爆点，搭配着用。

主线建议：自己博客原发 → dev.to 二发（填 canonical）→ Hacker News / Reddit 推一波 → Twitter thread 截要点。整套下来一篇内容能跑出三四种形式。

更多类似的开发者内容站和发布渠道，可以看 /c/dev 和 /c/content 两个分类。