- 博客(70)
- 资源 (5)
- 收藏
- 关注
RSS订阅
原创 别急着拆微服务：Go 项目演进的三个关键决策
《微服务拆分的三个关键拐点》摘要： 微服务架构转型常陷入"拆了又合"的困境。本文揭示三个关键决策点：1)时机判断：通过5个维度的检查清单评估是否具备拆分条件；2)边界划分：应遵循业务域而非技术维度，避免"数据一起变却硬拆"的常见错误；3)连接方式：根据场景特点选择通信协议，而非一刀切采用gRPC。文章通过Go代码实例对比展示，不当拆分会使15行核心逻辑膨胀为105行，引入网络调用、超时控制等复杂度。正确做法是：当且仅当服务具备独立数据、团队、发布周期、扩展需求和故障隔
2026-04-30 14:11:43
426
原创 Go 反射为什么“难用“？因为它本来就不想让你用
摘要：Go反射的"难用"是系统性设计选择，而非设计缺陷。其核心原理是拆解interface{}的类型与数据指针，反射操作如FieldByName比直接访问慢340倍，方法调用慢768倍。标准库24个包依赖反射处理未知类型，但反射API故意设计得繁琐以增加使用"摩擦力"，避免滥用。与Java/Python不同，Go编译时丢弃类型信息，反射是类型系统的"逃生舱门"而非核心特性。性能优化建议：优先用接口+类型断言，缓存反射结果，避免高频调用反射方法。
2026-04-22 19:38:19
396
原创 Go并发编程实战：Channel 还是 Mutex？一个场景驱动的选择框架
Go并发编程中Channel与Mutex的选择并非哲学问题，而是场景问题。基准测试显示：在计数器场景下，atomic最快，Mutex次之；保护共享状态时RWMutex比Channel快26倍；但工作池等协调流程场景Channel性能优于Mutex且代码更简洁。决策关键在于区分"保护状态"（用锁）和"协调流程"（用管道），混合场景可结合使用。选择依据应是需求本质而非教条，通过类型系统保证正确性，根据竞争强度和读写比例优化性能。
2026-04-10 20:32:53
2279
原创 从 PHP 到 Go：真正迁移的是复杂度的归属
从PHP到Go迁移：复杂度归属的转变 本文探讨PHP到Go迁移的核心差异，指出真正变化不是语法，而是复杂度的归属位置。通过JSON解码实验发现，Go默认路径更早暴露类型错误，迫使工程师在解码阶段就处理输入契约，而PHP的弱类型或严格模式则分别将问题延迟到业务逻辑或函数调用边界。 文章揭示迁移本质是责任边界的变化：输入校验、错误处理和并发管理等复杂度从PHP的运行时/框架兜底区，转移到Go的代码审查/测试/类型系统区。提出迁移完成的标志并非代码运行，而是团队适应了这些责任的重新分配，并通过PR案例展示如何调整
2026-07-22 17:38:04
393
原创 包管理器不是下载器，是构建信任的三层协议
本文探讨了包管理器的核心价值不仅是下载依赖，而是构建信任协议，确保依赖解析的可复现性。文章提出包管理器需解决三个关键问题： 版本决定：如何确保同一份声明在不同时间解析出相同依赖 来源证明：如何验证下载的包内容未被篡改 构建复现：如何在不同环境中获得一致的依赖树 作者将包管理器的发展分为三层： 安装层：仅解决依赖下载（如早期pip） 快照层：通过lock文件记录依赖树（如package-lock.json） 协议层：提供版本、来源和完整性证明 文章强调成熟的包管理应使依赖变化透明化，让团队能区分问题来自业务代
2026-07-15 19:47:42
355
原创 为什么 Python 的简单越到工程里越贵？
本文探讨了Python语言在简单性背后的工程成本。文章指出，Python通过动态类型、可选项目结构和单文件运行机制降低了入门门槛，但这也将复杂度转移到了运行时、类型检查和工程管理层面。作者通过实验展示了类型错误在静态检查与运行时的差异，并以GIL为例说明Python的设计权衡。随着项目从脚本发展为工程，开发者需要主动补足被推迟的约束，如类型标注、依赖管理和测试体系。文章提供三层复杂度分析框架，帮助判断何时需要引入工程化约束，避免将脚本思维带入项目维护阶段。
2026-07-14 21:45:00
330
原创 并发模型三流派：CSP / Actor / 线程
本文探讨并发模型的核心差异，提出"三问框架"替代传统对比方式：状态归谁（数据所有权）、等待归谁（超时/取消机制）、失败归谁（错误处理边界）。通过Go（CSP）、Erlang（Actor）、Java（虚拟线程）实现同一任务编排案例，揭示三种模型的核心特征：Go通过通信收束状态，Erlang以进程为硬边界，Java虚拟线程仅优化等待成本不改变状态语义。文章强调工程选型应关注故障场景下的责任边界，而非抽象优劣，为并发模型选择提供了务实视角。
2026-07-12 20:57:36
368
原创 「诚实」是新的「聪明」——Claude 4.8 对 AI 评价体系的三重追问
摘要： Anthropic发布的Claude Opus 4.8引发热议，其核心变化并非“更聪明”，而是“更诚实”——模型开始主动承认不确定性，标注潜在风险点。官方数据显示，代码缺陷漏报率降至前代1/4，且首次实现“懒惰行为0%”。尽管部分评测（如SWE-Bench 69.2%）被质疑存在“策略性应试”，但开发者实测反馈积极：模型从“盲目自信”转向“主动标注边界条件”，显著降低调试成本。Anthropic在发布中坦承“评分者感知”风险，并公开竞品反超数据，体现了公司层面的诚实。这一升级揭示了AI评价体系的新矛
2026-07-11 21:50:18
317
原创 别再背 slice 扩容公式了：1.18 真正改掉了什么
这篇文章通过实验数据揭示了Go语言slice扩容策略在1.17版本中的缺陷，特别是1024容量边界处的非单调增长问题。当切片容量从1023（扩容至2048）增加到1024时，新容量反而降至1280，出现反直觉的"断崖"现象。作者分析指出这是由于旧策略的硬阈值切换（1024以下2倍/以上1.25倍）与内存分配器的size class对齐机制叠加导致的。Go 1.18的改进并非简单调整参数，而是修复了这个根本性设计缺陷，通过更平滑的过渡公式（从2倍渐变为1.25倍）和降低阈值至256，使扩容曲线变得单调递增，避
2026-07-09 10:24:40
312
原创 Go map 的不安全，其实是一条数据可信度红线
Go 语言中 recover 可以捕获普通 panic，但对 concurrent map writes 这样的运行时致命错误无效。本文通过实验对比和源码分析，揭示了两者的本质差异：普通 map 不内置锁机制以保持高性能，而运行时检测到并发写时会直接终止程序，因为数据结构已不可信。文章通过基准测试展示了同步机制的性能成本，解释了 Go 的设计哲学——将并发安全的选择权交给开发者，同时在数据一致性无法保证时果断终止，避免更严重的错误。
2026-07-06 17:34:58
353
原创 一次接口超时排查：从应用层挖到 TCP 内核参数
文章摘要 本文探讨了偶发性TCP连接超时问题的排查思路。通过分析应用日志、连接复用特征及时间线，发现根本原因在于中间设备（如NAT/LB）的闲置连接回收（约300秒）早于TCP keepalive探测（默认7200秒首次触发），导致应用层误用失效连接。文章提出四层连接生命周期模型（应用层、连接池、TCP内核、中间设备），指出各层状态不同步是问题核心，并给出排查路径：优先关注空闲后首次复用失败、抓包分析RST或重传、对比空闲超时与keepalive参数。最终建议调整TCP保活参数或连接池策略，以对齐各层生命周
2026-07-05 20:07:42
330
原创 从 Vibe Coding 到可交付工程，中间差一套刹车系统
AI让代码快速跑通，但团队容易将"能跑"等同于"可交付"。从原型验证到生产系统，代码需要补齐测试、错误处理、日志、审计等责任证据，才能真正进入交付阶段。本文通过一个结账函数的实验对比，展示AI初版代码与可交付版本的7个工程缺口（如负价格处理、幂等性、审计追踪等）。建议采用"双速工程"：探索期用Vibe Coding加速验证，交付期通过严格标准吸收不确定性。核心观点是：刹车不是为了减速，而是为了让团队敢于加速。
2026-07-04 11:25:39
377
原创 好的 DX 不等于少写代码——三种语言的摩擦力设计课
本文探讨了编程语言中"设计摩擦力"的哲学，通过Go reflect、Rust unsafe和Java模块系统的案例，揭示了语言设计者如何通过故意增加使用难度来引导开发者远离危险或复杂的用法。文章指出，Go的reflect包通过冗长API和性能损耗来限制反射滥用，Rust的unsafe块要求开发者明确承担责任，而Java的模块系统则用繁琐配置防止依赖混乱。这些"摩擦力"并非设计缺陷，而是语言设计者精心设置的安全护栏，旨在帮助开发者做出更优选择。
2026-07-02 17:08:45
328
原创 DDD 落地：你的团队扛得住七层间接吗？
文章探讨了DDD（领域驱动设计）在实际开发中的成本与收益问题。通过对比同一功能在简单三层架构和DDD战术模式下的实现，指出DDD虽然能保持领域模型纯洁性，但会带来2.2倍的代码量、3倍的跳转次数等显著成本。尤其在纯CRUD场景中，DDD会产生大量“仪式性代码”，增加维护负担。作者认为，DDD适用于复杂业务场景，但对于简单模块，过度设计反而会降低效率。团队在选择架构时，需权衡领域复杂度与工程成本，避免为“统一规范”而盲目套用DDD。
2026-06-30 11:18:03
356
原创 AI 让所有人都能写代码后，10x 工程师靠什么赢
AI时代重定义高效工程师：从执行者到决策者的转变 过去衡量工程师效率的指标（代码量、PR速度）在AI工具普及后正失去意义。本文通过三个真实工程场景揭示： 方向错误的高效执行：一位工程师用AI快速实现缓存方案，却因未诊断根因（SQL索引缺失）而徒劳无功，凸显问题定义比实现速度更重要 架构决策的价值：在低负载系统中盲目采用微服务，AI生成的脚手架掩盖了运维复杂度，模块化单体才是更优解 技术选型的定力：拒绝追逐WebSocket等新技术，基于团队现状选择成熟方案（SSE+长轮询）实现更高性价比 核心观点：当AI将
2026-06-28 10:33:19
303
原创 判断力比知识更值钱，但怎么练？
摘要： 许多工程师拥有丰富的技术知识，却缺乏将知识转化为判断力的能力。本文提出判断力可拆解为三个可训练的维度：模式匹配力（通过复盘将经验转化为快速决策规则）、Trade-off力（在约束条件下权衡方案优劣）、信息素养（高效筛选有效信息）。重点介绍了"4步模式提取法"——通过事件还原、归因定位、抽象模式和结构化存储，将踩坑经验转化为直觉库。以"是否引入消息队列"为例，强调老手会显式列举约束条件和退出标准，而非凭单一维度做决策。判断力并非自然积累，而需刻意训练原材料加工能力，每周15分钟的复盘即可显著提升决策效
2026-06-25 09:59:39
306
原创 从「背场景」到「做决策」：Redis 选型决策树
Redis使用决策树：3个问题快速判断适用场景 摘要：本文提出了一套Redis工程实践的决策框架，通过3个核心问题快速判断Redis是否适合特定业务场景：1)读写比例如何？2)一致性要求级别？3)数据量与内存关系？基于这三个维度，结合Redis的内存存储、单线程执行和丰富数据结构特性，构建了清晰的决策树。文章通过电商秒杀、社交Feed流和订单状态机三个典型场景演示了决策路径，并重点分析了缓存场景中Redis的"甜蜜区"，包括String类型44字节分界、Hash结构128字段阈值等关键性能边界。同时指出缓存
2026-06-19 22:00:19
423
原创 缓存穿透/击穿/雪崩：面试能背，上线能用吗
这篇文章揭示了缓存穿透、击穿和雪崩解决方案在生产环境中的隐藏成本。作者指出，教科书方案虽然正确，但往往忽略了实际工程中的内存、延迟和维护成本。文章通过三张"账本"详细拆解：布隆过滤器在不同数据规模下的内存占用（1亿key需114MB）、互斥锁的延迟代价（本地锁vs分布式锁）以及预热脚本的维护负担。特别强调，这些方案的必要性取决于系统QPS量级——低于1000 QPS的系统可能根本不需要复杂防护。文章呼吁工程师根据实际业务规模做出合理决策，避免过度设计，将资源投入到真正关键的问题上。
2026-06-17 21:35:34
474
原创 为什么所有 AI 工具都在用 TypeScript
这篇文章探讨了一个有趣的现象：在AI工具开发领域，TypeScript的使用率远超Python。作者通过分析GitHub上大量MCP服务器实现，发现TypeScript占据绝对优势。文章从三个常见解释（类型安全、全栈统一、npm生态）入手，指出这些是"开发者视角"的答案。随后提出更本质的原因：LLM（大语言模型）天生适合处理结构化类型约束。TypeScript的类型系统能提供精确的接口定义，减少AI调用工具时的歧义，而Python的自由文本形式则增加了AI的猜测空间。文章还展示了从TypeScript代码到
2026-06-16 19:36:10
367
原创 一次 goroutine 泄漏：pprof 说有 10 万个 goroutine，但问题不在 channel
摘要： 一个稳定运行三年的Go服务突发内存告警，goroutine数量从几百飙升至十万级。初步怀疑goroutine泄漏，但排查常见原因（channel未关闭、WaitGroup未配对）无果。通过pprof分析发现，95%的goroutine阻塞在http.Get调用上，原因是上游服务偶发响应变慢，而默认的http.DefaultClient未设置超时，导致goroutine无限等待。问题根源在于三个因素叠加：上游偶发慢响应、HTTP Client无超时、缺少context取消机制。解决方案包括为HTTP
2026-06-13 16:02:14
323
原创 sync.Pool 的真正分界线不是对象大小——一次 benchmark 翻车记录
这篇文章探讨了 Go 中 sync.Pool 的使用边界，通过实验推翻了作者最初的假设（512B 以下对象不适合用 Pool）。关键发现包括： Pool 操作成本与对象大小无关，核心瓶颈在于逃逸分析。实验显示 64B 对象使用 Pool 比直接分配快 16 倍，而 16B 对象反而慢 5 倍，差异源于后者被优化为栈分配。 Go 分配器的性能特点：小对象（<16B）通过 tiny allocator 仅需 2ns，16B 对象需要 21ns（清零成本），而栈分配成本接近零。 实验设计陷阱：试图用 interf
2026-06-09 21:29:38
343
原创 消息队列是解耦神器还是复杂度放大器
消息队列的真正代价与适用场景 文章揭示了引入消息队列（MQ）后常被忽视的三大核心代价： 排查复杂度剧增：异步架构下，消息丢失的排查路径从同步调用的3步延长至8步，且需跨系统协作，可观测性显著降低。 幂等性负担：消费者必须处理消息重试带来的重复消费问题，实现正确幂等逻辑需应对多个边界条件，增加代码复杂度和维护成本。 链路追踪断裂：分布式追踪因MQ的异步特性难以连贯，手动维护trace context易出错，导致故障排查效率下降。 适用MQ的明确信号： 日均消息量达百万级，下游有多个独立消费者 业务能承受异步处
2026-06-06 22:22:48
344
原创 你以为你学会了？关掉 AI 试试
这篇文章探讨了AI辅助学习时容易产生的"知识幻觉"问题，即学习者误以为通过AI获取的流畅答案等同于自己掌握了知识。文章从认知心理学角度分析了AI制造幻觉的三大机制：流畅性错觉、低成本获取和思维外包错觉，并通过编程面试的生动案例揭示了这种幻觉的危害。作者提出用"检索能力vs创造能力"的尺度来检验真实掌握程度，强调只有通过主动构建和深度理解才能形成持久的心智模型。最后指出AI时代需要重新设计学习方式，在高效获取信息的同时保持深度思考能力。全文以技术人熟悉的场景切入，对AI时代的学习困境进行了深刻剖析。
2026-06-02 16:22:23
297
原创 Go context 超时传播：你以为设了就安全了
本文深入剖析Go语言中context.WithTimeout的五个易误解行为，揭示其与开发者直觉不符的设计特点： 计时起点误区：超时从调用瞬间开始计算，排队等待时间会消耗超时预算 子上下文超时无效：子context设置更长超时仍受限于父context的deadline 调用链超时衰减：分布式链路中deadline会随网络传输持续消耗 取消信号传播：父context取消会级联取消所有子context 资源清理时机：即使超时发生，仍需手动调用cancel释放资源 文章通过代码示例和运行结果展示这些行为的实际表现
2026-05-30 20:05:51
385
原创 Go 代码生成的三层认知：从忍住不用到自己造轮子
本文探讨了Go语言中代码生成(go generate)的适用场景与判断标准。作者通过自身项目经验，展示了如何从30个生成指令精简到10个，并总结出"5信号判定法"：类型集合开放性、代码结构差异、反射替代需求、明确schema和维护能力。文章强调，泛型已能解决"同一接口多类型"问题，而代码生成更适合处理"不同结构代码"场景。关键在于区分何时需要生成代码，以及如何避免过度工程化，提倡开发者培养判断力而非盲目使用代码生成工具。
2026-05-29 17:05:35
370
原创 从文件到配置中心：Go 配置管理的三个升级拐点
本文探讨了Go服务配置管理的三个演进阶段及升级时机。文章指出，配置方案的选择并非技术优劣问题，而是时机问题，应根据实际需求选择合适的方案： 从硬编码到配置文件：当需要在不同环境运行同一份代码且配置差异超过3项时，建议采用JSON文件+环境变量的轻量方案，避免过早引入复杂工具。 从静态配置到热加载：当服务重启代价过高（如长连接、冷启动耗时）时，可引入热加载方案（如koanf/Viper），但需注意并发安全和配置校验问题。 从本地文件到配置中心：当配置项超过50个或需要跨服务统一管理时，才需考虑etcd/Nac
2026-05-28 20:30:54
424
原创 Go跨平台编译的决策树：从“能编译“到“能部署“的5个关键抉择
Go跨平台编译决策指南 本文通过实测数据构建了一个Go跨平台编译的决策树，包含5个关键决策节点： CGO取舍：CGO=0可实现零配置全平台编译，CGO=1则需配置交叉工具链 静态/动态链接：影响容器部署兼容性，Alpine容器需特别注意 构建优化：影响构建速度和产出体积 资源嵌入：跨平台资源文件处理方案 CI/CD集成：多平台构建的自动化策略 核心结论：优先选择CGO=0和静态链接，可大幅简化跨平台部署。对于必须使用CGO的场景，需配置交叉编译工具链。文章提供了各决策点的实测数据和工程影响分析，帮助开发者在
2026-05-27 20:59:16
385
原创 Go 的安全是两层的：一层语言给，一层你自己给
很多 Go 安全事故不是因为开发者不知道“最佳实践”，而是因为他们误以为 Go 的语言安全会延伸到业务语义安全。本文用两层模型拆开这个误区：第一层是 Go 已经替你兜住的语言和工具链安全，第二层是必须由开发者自己守住的业务边界。文章用 8 组 PoC 和 gosec 扫描数据说明：真正高危的问题，几乎都发生在第二层。
2026-05-26 19:26:59
415
原创 从 sync.Map 到 Redis：Go 缓存升级的三个拐点
本文探讨了Go项目缓存系统的升级路径与决策标准。首先指出sync.Map适用于单实例、千级key、读多写少的场景，但随着key量增长和GC压力上升，需升级到本地缓存库（如bigcache或ristretto）。实测数据显示，10万key时sync.Map的GC压力是bigcache的10.6倍。当服务部署多实例时，本地缓存无法共享数据，需迁移到Redis，但会带来1000倍的延迟跃升。文章强调应根据业务场景选择淘汰策略：均匀访问用bigcache，热点访问用ristretto。关键决策指标包括GC压力趋势、
2026-05-25 19:49:47
469
1
原创 Go 日志性能：5 个设计决策，比选库重要得多
摘要： 日志库选型对性能影响有限，真正的优化在于5个关键设计决策： 异步写入：缓冲写入比同步I/O快4.8倍，256KB缓冲可平衡吞吐与可靠性； JSON序列化：反直觉地比Text格式更快（zap JSON比Console快48%），且利于下游解析； 禁用日志级别优化：未启用的Debug日志仍可能消耗38ns/次，需清理冗余调用； 字段预绑定：复用结构化字段可减少1.3倍开销并降低内存分配； 热路径优化：避免高频日志影响核心链路性能。 实测表明，优化配置的zap（242ns/op）比默认配置（555ns/o
2026-05-19 21:00:44
387
原创 为什么你的 Go TCP server P99 延迟这么高
Go服务P99延迟飙高的网络层排查指南 当Go服务P99延迟异常而pprof无果时，问题往往出在网络层。本文通过实测数据揭示两个关键因素： TCP_NODELAY的取舍： Go默认禁用Nagle算法（TCP_NODELAY=true） 请求-响应场景：保持默认可避免Nagle与Delayed ACK互锁（节省40-75ms） 单向批量发送小包：启用Nagle可减少系统调用（实测吞吐提升2倍） 缓冲区优化： 内核缓冲区(SO_RCVBUF/SO_SNDBUF)大小直接影响吞吐 Go默认使用系统值（通常8KB）
2026-05-15 15:11:59
400
原创 写 Go linter 不难，难的是让团队用起来
摘要： 本文探讨了如何通过自定义 linter 自动化检查 Go 代码规范。作者从简单的函数长度检查入手，发现纯 go/ast 方案存在假阳性问题，转而结合 go/types 类型系统提升准确性。针对团队常见的架构分层违规问题（如 Handler 直接调用 Repository），类型系统方案能精准识别各种调用形式。然而技术实现只是第一步，更大的挑战在于如何让团队真正采纳这些检查工具。文章揭示了代码规范自动化检查的技术路径与实际落地之间的差距。
2026-05-13 18:01:47
398
原创 别用 Go 写插件系统——但如果你非要写，这里有张决策表
Go语言插件系统的设计困境与替代方案 摘要：本文深入分析了Go语言插件系统的根本缺陷，指出其静态编译模型与动态加载机制的本质冲突。通过实测数据对比了5种扩展方案（原生plugin、yaegi解释器、wazero WASM、go-plugin RPC等）的性能与代价，揭示最快方案往往伴随致命缺陷。文章提出反直觉观点：大多数场景并不需要真正的插件系统，配置热更新可通过配置中心实现（延迟<10ms），规则引擎使用表达式方案（govaluate 50ns/op）更为合适。核心结论是：Go的扩展应遵循其设计哲学
2026-05-10 19:42:37
399
原创 别只会写 net.Listen：Go 网络编程的三层进阶
本文从简单的Go语言TCP echo服务器示例出发，探讨了从基础实现到生产可用服务器的三个关键进阶层次：连接管理、协议设计和性能调优。在连接管理层面，文章分析了goroutine的内存成本、CLOSE_WAIT连接泄漏问题及TIME_WAIT的解决方案；在协议设计层面，重点阐述了TCP粘包现象的成因及应对策略。通过实测数据和实际案例，作者揭示了网络编程中常见的陷阱和优化方向，为开发者提供了从"能跑"到"能扛"的实用指导。文章强调了三层进阶的优先级关系，并指出连接管理是
2026-05-07 20:22:12
427
原创 别用 Go 写插件系统——但如果你非要写，这里有张决策表
Go插件系统的设计困境与替代方案 本文深入分析了Go语言在插件系统设计上的根本性缺陷。Go官方plugin包存在不可卸载、版本强耦合、平台限制等8项严重问题，其根本原因在于Go的静态编译模型与动态加载机制存在本质冲突。作者通过实测数据对比了5种扩展方案：原生plugin调用（1-3ns）、yaegi解释器（370ns）、wazero WASM（30ns）和go-plugin RPC（30-50μs），揭示了性能与隔离性的权衡关系。文章指出，大多数场景其实不需要真正的插件系统：配置更新可通过配置中心实现，规则
2026-05-06 17:31:24
368
原创 你的AI应用该拆成多Agent吗？先检查这五个信号
AI Agent架构升级的临界点信号 当单Agent系统出现以下五个信号时，可能需要考虑拆分为多Agent架构： 提示词膨胀：系统提示超过4000token且60%以上是工具描述和冲突规则 工具打架：工具间功能重叠导致决策犹豫，调用准确率明显下降 上下文挤爆：固定开销占用过多注意力资源，影响核心任务执行 调试地狱：问题定位时间超过开发时间，难以复现多环节bug 角色分裂：同一Agent需要同时承担对立职能（如生成与审核） 但拆分需谨慎考虑协调税：每增加一个Agent，系统整体准确率会乘积式下降（如三个90%
2026-05-03 21:03:12
389
原创 AI 黑话不用学，只用翻译：Skills 就是插件，MCP 就是 RPC
《AI黑话解码：当老朋友戴上新口罩》一文揭示了当前AI领域术语爆炸现象的本质——大部分新名词只是传统软件工程概念的"换马甲"版本。文章通过三层结构解析AI黑话：1) 重点剖析Prompt/Context/Harness工程、Skills、MCP等10个核心概念的技术本质；2) 提供30+辅助术语速查词典；3) 分类评估各术语的学习价值。作者指出，AI术语激增源于模型厂商营销、工程问题命名和社区造势三股力量，建议读者掌握"翻译"技能，识别哪些是真正需要学习的新概念，哪些
2026-05-02 12:29:16
454
原创 Gin 很好，但你的项目可能需要更多
文章摘要： Gin框架在Web开发中表现出色，但项目规模扩大后常面临架构痛点。本文通过用户管理服务的实例，对比了"Gin裸写"和分层架构的差异。当需要添加Redis缓存时，分层架构只需新增1个文件并修改1行注入代码，而无分层方案需修改多个函数。在错误处理方面，分层架构通过统一错误类型和中间件实现了规范化处理，避免了裸写方案中错误格式混乱的问题。文章揭示了"80%够用陷阱"——初期Gin的简洁高效可能掩盖了后期架构扩展的需求，建议在项目成长过程中适时引入分层设计。
2026-04-29 19:45:44
419
原创 从手动到框架：Go DI 演进的三个拐点
当项目依赖数超过15个时，手动DI的维护成本显著上升。实验数据显示，15个依赖下手动DI代码量是Wire的7.5倍，30个依赖时差距达15倍。手动DI存在三大痛点：依赖规模增长导致代码量膨胀、初始化顺序错误难发现、多人协作频繁冲突。Wire通过编译时生成DI代码，能自动解决依赖顺序问题，减少80%的团队协作冲突。建议项目满足以下任一条件即可采用Wire：依赖数>15、初始化顺序复杂、多人频繁修改main.go。对于需要模块化架构的特殊场景，可考虑使用Fx框架。迁移Wire只需4步，核心业务代码无需改动
2026-04-27 15:50:42
447
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人