最近在技术社区和开发者群里经常能看到一种声音“感觉没东西可写了。” 这背后反映的不是一个简单的灵感枯竭问题而是一个普遍存在的技术成长瓶颈。很多开发者尤其是处于职业生涯早期或中期的朋友在掌握了基础语法、完成了一些项目后会陷入一个“平台期”日常工作是重复的业务逻辑新技术层出不穷却不知如何下手想分享经验又觉得自己的东西太“基础”不值一提。这种“没东西发”的焦虑本质上是输入与输出的失衡以及对“有价值内容”的认知偏差。本文将从一个资深技术作者的角度系统性地拆解这个问题并提供一套可落地的解决方案。我们不止探讨“写什么”更会深入分析“为什么写不出来”以及“如何持续地写出被认可的内容”。读完本文你将能诊断自己“没东西可写”的根本原因。建立一个可持续的、低门槛的技术输入与选题挖掘系统。掌握将零散知识、踩坑经验转化为高质量技术文章的完整流程。避开新手写作时常见的认知误区和实操陷阱。1. “没东西可写”的真相三大认知陷阱在开始寻找选题之前我们必须先破除几个根深蒂固的错误观念。这些观念是导致你提笔困难的首要障碍。陷阱一只有“高精尖”的创新才值得分享这是最大的误区。很多开发者认为必须像发表论文一样提出全新的架构、算法或框架文章才有价值。事实上技术社区的绝大多数读者面临的是和你相似的、具体的、琐碎的问题。一个清晰解决NullPointerException排查思路的帖子可能比一篇晦涩的分布式事务理论综述帮助的人更多。价值不在于主题的宏大而在于解决问题的深度和清晰度。陷阱二我的经验太“普通”别人早就知道了这是一种典型的“知识的诅咒”——你熟悉的东西会下意识认为别人也熟悉。你花三天解决的一个诡异的 Maven 依赖冲突背后可能涉及仓库配置、依赖传递、版本锁定等多个知识点。对你而言是“普通”的踩坑对另一个刚遇到此问题的新手来说就是雪中送炭的指南。技术写作的第一价值是“记录”第二价值才是“创造”。陷阱三必须等完全精通了才能动笔追求完美是写作的最大敌人。没有人能在动笔前就穷尽某个主题的所有细节。写作本身就是一个深度学习和梳理的过程。你可以写一篇“初探”记录自己的学习路径和理解可以写一篇“实战”记录项目中的集成过程也可以写一篇“踩坑”记录解决问题的曲折历程。“边学边写以写促学”是最有效的成长方式。2. 构建你的“技术选题雷达”从输入到输出的系统方法解决“没东西写”的关键是建立一个稳定的“选题输入”系统。这个系统就像雷达持续扫描你的技术活动将潜在的写作素材标记出来。2.1 输入源挖掘你的日常就是宝藏你的日常工作、学习和生活中有大量未被意识到的选题工作项目技术选型为什么在项目 A 中选择 Redis 而不是 Memcached它们的性能对比数据是什么配置上有何不同架构设计微服务拆分时你是如何界定服务边界的遇到了哪些数据一致性问题性能优化某个 API 接口从 200ms 优化到 20ms你用了哪些手段数据库索引、缓存、异步化、算法优化BUG 排查那个让你加班到凌晨的线上 Bug它的根因是什么排查链路是怎样的注意脱敏学习过程新框架/工具上手学习 Spring Cloud Alibaba、Vue 3、ClickHouse 时第一个让你卡住的点是什么官方文档没讲清楚的地方在哪读书笔记读《Effective Java》、《设计模式之美》时哪一条建议让你恍然大悟能否结合一个自己代码中的反例来说明源码阅读看某个开源库如 Guava、MyBatis的源码时哪个巧妙的设计让你印象深刻画个简图分析一下。社区互动解答他人问题你在 Stack Overflow、技术群里帮别人解决的问题稍加整理就是一篇好文章。复现他人项目GitHub 上一个 star 很高的项目你跟着跑一遍记录下环境配置、运行步骤和遇到的坑。2.2 选题加工从“点”到“文章”有了零散的“点”下一步是将其加工成有结构的“文章”。这里提供一个万能公式选题 具体场景 解决方案 深度延伸 通用总结具体场景不要写“如何优化 SQL”要写“在千万级用户评论表中如何优化‘根据用户ID分页查询最新评论’的 SQL”。解决方案详细记录你尝试的每一步包括失败的和成功的。深度延伸为什么这个方案有效背后的原理是什么例如为什么覆盖索引能解决这个问题通用总结从这个具体案例中可以提炼出哪些普适性的方法论或最佳实践3. 环境准备打造高效的写作工作流写作不是打开编辑器就写。一个高效的环境能极大降低启动成本。3.1 工具链选择写作工具Typora、VS Code Markdown 插件、Notion。选择你用得最顺手的核心是支持 Markdown便于发布到 CSDN、掘金等平台。图床工具PicGo GitHub/OSS。文章中的截图、流程图需要稳定可靠的图床。代码管理所有文章中的示例代码建议同时在 GitHub 上维护一个仓库。这既是备份也方便读者克隆运行。素材管理用笔记软件如 Obsidian、OneNote建立一个“选题库”文件夹随时记录灵感。3.2 建立写作模板为不同类型的技术文章准备模板可以让你快速进入状态。例如「问题排查类」模板问题现象贴错误日志环境说明OS, JDK, 框架版本排查思路与步骤像侦探破案一样写根因分析技术原理深挖解决方案总结与预防建议「工具集成类」模板背景与选型理由环境准备依赖、配置核心配置详解基础使用示例进阶特性与坑点生产环境建议4. 从零到一完成你的第一篇技术文章让我们以一个最具体的例子走通从选题到发布的完整流程。假设选题是“Spring Boot 项目集成 Prometheus 监控时如何自定义一个业务指标并暴露”4.1 第一步明确目标与大纲目标让读者能跟着文章在自己的 Spring Boot 项目中成功添加一个自定义的业务监控指标。大纲为什么需要自定义业务监控场景引入快速创建一个 Spring Boot 项目添加 Micrometer 和 Prometheus 依赖使用MeterRegistry创建自定义计数器Counter编写一个 Controller 来触发指标增长配置并启动 Prometheus 来抓取指标在 Grafana 中可视化自定义指标常见问题排查指标不出现、标签使用错误等4.2 第二步准备示例项目创建一个干净的 Spring Boot 项目是可信度的基础。# 使用 Spring Initializr 创建项目 # 访问 https://start.spring.io/ # 选择Project: Maven, Language: Java, Spring Boot: 3.x # Dependencies: Spring Web, Spring Boot Actuator, Micrometer Registry Prometheus # 生成并下载项目解压后项目pom.xml关键依赖应如下所示!-- pom.xml -- dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId scoperuntime/scope /dependency /dependencies4.3 第三步编写核心代码与讲解1. 创建自定义指标服务我们创建一个服务用来记录“用户订单创建”这个业务动作的次数。// 文件路径src/main/java/com/example/demo/service/OrderMetricsService.java package com.example.demo.service; import io.micrometer.core.instrument.Counter; import io.micrometer.core.instrument.MeterRegistry; import org.springframework.stereotype.Service; import jakarta.annotation.PostConstruct; Service public class OrderMetricsService { private final MeterRegistry meterRegistry; private Counter orderCreatedCounter; public OrderMetricsService(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } PostConstruct public void init() { // 创建名为 order.created 的计数器并添加一个 type 标签用于区分订单类型 orderCreatedCounter Counter.builder(order.created) .description(The total number of created orders) .tag(type, normal) // 默认标签 .register(meterRegistry); } /** * 模拟订单创建并增加计数器 * param orderType 订单类型如 normal, vip */ public void createOrder(String orderType) { // 业务逻辑... System.out.println(Creating order of type: orderType); // 关键增加计数器并动态指定标签值 meterRegistry.counter(order.created, type, orderType).increment(); // 也可以使用之前创建的计数器但标签是固定的 // orderCreatedCounter.increment(); } }代码解释PostConstruct确保服务初始化时创建指标。Counter.builder(“order.created”)定义了一个计数器指标。.tag(“type”, “normal”)添加了一个维度标签这是 Prometheus 监控的强大之处可以按维度聚合。在createOrder方法中我们使用meterRegistry.counter(...)并传入动态的orderType标签值。这比使用固定标签的计数器更灵活。2. 创建触发业务的 Controller// 文件路径src/main/java/com/example/demo/controller/OrderController.java package com.example.demo.controller; import com.example.demo.service.OrderMetricsService; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class OrderController { private final OrderMetricsService orderMetricsService; public OrderController(OrderMetricsService orderMetricsService) { this.orderMetricsService orderMetricsService; } GetMapping(/order/create) public String createOrder(RequestParam(defaultValue normal) String type) { orderMetricsService.createOrder(type); return Order created with type: type; } }4.4 第四步配置与运行验证1. 应用配置为了让 Actuator 暴露 Prometheus 端点需要在application.properties中配置# application.properties # 暴露所有 Actuator 端点生产环境应更精细控制 management.endpoints.web.exposure.include* # 设置应用名称会作为指标前缀 application_name spring.application.namedemo-prometheus2. 启动应用并访问指标mvn spring-boot:run应用启动后访问http://localhost:8080/actuator/prometheus。你应该能看到一堆指标其中包含我们自定义的# HELP order_created_total The total number of created orders # TYPE order_created_total counter order_created_total{typenormal,} 0.03. 触发业务观察指标变化在浏览器中访问http://localhost:8080/order/create?typenormalhttp://localhost:8080/order/create?typeviphttp://localhost:8080/order/create?typenormal再次刷新http://localhost:8080/actuator/prometheus你会看到order_created_total{typenormal,} 2.0 order_created_total{typevip,} 1.0这表明我们的自定义业务指标已经成功生成并且按type标签正确区分。4.5 第五步集成 Prometheus 与 Grafana简述为了让文章更完整可以简要介绍如何让 Prometheus 采集这个指标并在 Grafana 中展示。Prometheus 配置(prometheus.yml)scrape_configs: - job_name: spring-boot-app metrics_path: /actuator/prometheus static_configs: - targets: [localhost:8080]启动 Prometheus和Grafana。在 Grafana 中添加 Prometheus 数据源然后新建一个 Panel使用查询rate(order_created_total[5m])来查看订单创建速率。5. 文章撰写将代码转化为有观点的内容有了上面的实操基础写作就是把过程、思考和原理讲清楚。开头不要直接写“本文介绍Spring Boot集成Prometheus”。可以这样切入“在微服务架构下我们监控了CPU、内存但业务是否健康比如订单创建量是否异常今天我们就来解决如何为Spring Boot应用添加‘业务脉搏’监控。”原理部分解释 Micrometer 是什么监控门面它和 Prometheus监控系统的关系。用比喻Micrometer 就像 JDBC定义了接口Prometheus 就像 MySQL是一种具体实现。代码部分就像上面那样给出完整、可运行的代码并解释关键行。坑点部分这是精华。比如标签Tag的值必须是有限的、枚举型的不要用用户ID这种高基数数据否则会把 Prometheus 搞崩。Counter、Gauge、Timer、Summary分别适用于什么场景指标命名最好遵循xxx.yyy.zzz的格式。6. 常见问题与排查思路问题现象可能原因排查方式解决方案访问/actuator/prometheus返回 4041. 依赖未正确添加2. 端点未暴露1. 检查pom.xml是否有micrometer-registry-prometheus2. 检查application.properties的management.endpoints.web.exposure.include配置1. 添加依赖2. 配置为*或prometheus,health,info自定义指标在端点中看不到1. 指标名称拼写错误2. 指标未被注册3. 标签值包含非法字符1. 检查代码中builder(“order.created”)的名字2. 确保register(meterRegistry)被调用3. 检查标签值是否包含空格、点等1. 修正名称2. 检查初始化逻辑如PostConstruct3. 规范标签值Prometheus 抓取不到数据1. 网络不通2.prometheus.yml配置错误3. 应用路径或端口不对1. 在 Prometheus 服务器用curl手动访问应用端点2. 检查 Prometheus 的 Targets 页面状态3. 核对配置中的targets和metrics_path1. 解决网络问题2. 修正配置文件3. 重启 Prometheus7. 技术写作的最佳实践与进阶建议一图胜千言对于架构、流程、关系尽量使用流程图、时序图用 draw.io 或 ProcessOn 绘制。截图要清晰关键部分可以加红框标注。版本说明至关重要在文章开头明确给出环境版本如 Spring Boot 3.1.5, JDK 17。这能避免大量因版本差异导致的读者问题。代码的完整性确保提供的代码片段是完整的、可编译的。最好在文中提供 GitHub 仓库链接。由浅入深的结构先给一个“最小可行示例”MVP让读者快速跑通获得正反馈再深入讲解原理和高级特性。主动提出并回答问题在文章中预设读者可能会问的问题并以“QA”或“注意事项”的形式给出答案。这体现了你的预见性和经验。保持更新技术迭代快如果文章涉及的工具版本有重大更新可以在文末注明或后续写一篇更新文章。8. 总结从“没东西发”到“发不过来”“没东西发”是一个伪命题。你的每一次技术探索、每一个解决的问题、每一段读源码的感悟都是独一无二的内容素材。关键在于转变心态并建立一套系统化的方法心态上拥抱“记录”的价值破除“完美”和“高深”的执念。方法上建立“选题雷达”从工作、学习、交流中持续捕捉素材。行动上使用“场景-方案-延伸-总结”的公式加工素材并借助模板和工具流高效成文。内容上追求深度而非广度把一个点讲透提供可运行的代码和可复现的步骤。开始写第一篇。哪怕只是记录今天解决的一个小 Bug。写作是技术人最好的学习方式、思考方式和连接方式。当你通过文章帮助了别人获得了反馈甚至结识了同道你会发现不是“没东西发”而是好东西“发不过来”。