9号达人

又到了一年一度的年终总结季。现在应该叫去年了，相信大家或多或少都会带上ai这个关键词。 如果让我选今年最大的改变，不是写代码，不是生图，而是搜索。 AI让搜索这个能力，彻底平权了。 以前，搜索质量取决

上周接到客服反馈。 有些商户开通之后，微信支付功能不能用，有些又可以。不能用的商户就需要客服手动介入，重新配置支付参数才恢复正常。 这个问题就很诡异，时好时坏。有时候正常，有时候就不行。 但是后台日志

事故现场 上周线上炸了。 支付业务出了问题，用户支付成功，但订单表没数据。更诡异的是，修改订单时有时也会提示获取锁超时。 DBA看了一眼数据库连接，发现几个事务一直没提交，锁着订单表的几行数据。 排查

最近在开发过程中遇到了一个的挺有意思的验签问题。我们的项目采用了前后端签名验证机制来保证数据安全： 前端：请求时对 body 进行签名 后端：接收后对 body 进行验签 正常情况下都没啥问题，但这次

概念来源 "银弹"（Silver Bullet）这个概念来自于弗雷德里克·布鲁克斯（Fred Brooks） 的经典著作《人月神话》（The Mythical Man-Month）。 1986年，布鲁

最近去另一个业务组帮忙一起开发优惠系统。我们的老项目采用的是实时结算模式：用户看到优惠 → 直接下单 → 按实际优惠结算。前端展示优惠信息，用户下单后，后端直接根据当前优惠规则计算最终的优惠金额。 但

问题背景 最近在写接口的时候，遇到了一个看似简单但实际很坑的参数校验问题。代码是这样的： 看起来很完美对吧？使用的是 javax.validation.constraints.NotBlank 注解来

背景 最近在开发微服务项目时遇到了一个典型的技术决策场景：我们的商品服务通过 Dubbo 对外提供了一个商品列表查询的 RPC 接口，目前被网页端系统调用。现在 PC 端管理系统（新的调用方）也需要类

前言 作为一个普通公司的后端，最近在负责 SaaS 的对账系统重构。理想很丰满，现实很骨感。今天想聊聊小公司做对账系统时，可能会遇到的一些真实问题。 一、理想与现实的差距 1.1 理想中的数据分层架构