后端

IM网关系列（九）单账号流量统计：滑动窗口桶方案设计与Go实现IM网关是长连接接入层（WebSocket为主），需要对上行消息做限流防护：防止真人账号刷屏、机器人刷消息、恶意账号打满带宽、群组消息风暴拖垮后端。需求约束：

Embedding 替换怎么评测：把索引成本算进成功任务一个检索模型在公开榜单上分数更高，接入知识库后却可能让任务更贵。原因常常在检索之后：Agent 拿到片段是否足够作答、是否继续改写查询、是否把整篇文档展开、失败时是否重新调用工具。这些动作会消耗生成模型的 Token 和时间。只看一次向量请求的单价，观察不到整条链路的变化。

on-failure 不扛重启：一次 Docker restart 策略的反直觉排查主题：容器构建与编排卫生restart: on-failure 不能扛住宿主机/Docker daemon 重启 —— 只有 unless-stopped 能。

GM指令：仓库扩容、清空仓库（行会仓库 + 个人仓库，Lua + proto + GMMgr注册）适配之前 StoreMgr（个人仓库）、行会仓库模块；权限分级，日志埋点，防误删保护

不报错 ≠ 生效：三类"静默失效"缺陷与它们的共同指纹主题：请求校验与静默失效有一类 bug 特别阴险：代码/配置"看着改了"，但在运行时根本没起作用 —— 而且不抛异常、不打日志。

整理背包 SortBag 完整实现逻辑核心目标：堆叠同类、按规则排序、空位后置、锁定物品位置不动，不修改物品属性（强化、时效、绑定、唯一性）前置前提：背包是数组结构 items[pos]，pos 从 1~最大格子数；格子分【锁定格子】和【普通格子】

Marcus学原理

Playwright 入门：让浏览器自动完成重复操作每天打开后台、填写标题、上传图片、保存草稿——这些操作并不难，却很重复。Playwright 可以让程序接管浏览器，按步骤完成它们。

后端 Web 实战：部门管理模块全流程（前后端分离 + RESTful + 三层架构 + 日志）大家好！前面几篇我们把 Web 开发的基础知识都过了一遍：Maven、HTTP 协议、SpringBootWeb、IOC/DI、MySQL、JDBC、MyBatis…… 从这一篇开始，我们就要进入后端 Web 实战篇了——把前面学的东西全部用起来，完成一个大的综合案例：Tlias 智能学习辅助系统。

背包<->仓库转移接口（BagMgr + StoreMgr，Lua）前提：已经有 BagMgr（背包）、StoreMgr（仓库）、ConfigMgr、EventMgr、LogMgr、PlayerMgr；物品结构统一，item_uid 唯一。支持：背包→仓库、仓库→背包；支持单个物品、支持可堆叠物品数量拆分；校验负重、仓库容量、物品锁、限时物品是否允许存仓。

设计模式中模板方法的钩子使用模板方法属于行为型设计模式。核心思想：结构：调用：钩子方法两种常见用途：示例（空钩子）：在模板中：适合：一套流程固定，但其中部分细节 / 可选分支需要不同实现

我的div丢了肿么办

go语言对路由中的业务逻辑进行抽离现在我们的路由和业务逻辑是在一起的；这样会导致路由和业务逻辑耦合度高，不利于维护。为了将路由和业务逻辑分离，我们可以将业务逻辑抽离到控制器中。控制器是一个处理路由请求的函数，它负责接收路由参数，调用业务逻辑，返回响应。与main.go同一级中，创建一个controllers/user/userController.go文件

纯Rust重写Photoshop，一个月7.2万Star这周 GitHub 上有个项目让我看愣了。`storytold/photocraft`，纯 Rust 从零重写的 Photoshop。9 月 30 日建仓，不到一个月 71,991 star，12,719 fork。

Kubernetes 通过资源 requests 决定 Pending Pod 能否找到节点前言：前几天给预览服务接上了外部入口，我又把 Deployment 的副本数从一份调成两份，想让更新时更从容。结果新 Pod 一直是 Pending，而节点监控看着并没有跑满。我第一反应是等一会儿，或者把容器的内存上限调小。翻了 Kubernetes 的资源管理文档才发现：调度器决定“能不能安排座位”，看的主要是资源 requests。于是问题来了：没有明确写需求时，我们怎么安排资源？写了 requests 后，为什么机器看着空闲，Pod 还是进不去？

用户36005557900

Kestrel_VLLM - 18 · 投机解码位级对拍收口：batch 与 M=1 一致，注意力路径与 CPU 逐字节对齐一句话：把「M>1 batch verify 与 M=1 decode」的对拍从 top-1 下沉到完整 logits 逐字节，纠正一处 64-token 长序列的误读，并把 CPU↔GPU 的分歧一路消到 layer 0 的 MoE FFN 为止——层 0 整条注意力路径（RMSNorm → QKV GEMM → QK-norm → RoPE → KV 量化 → attention → O 投影+残差）已与 CPU 逐位全等。前置：建议先读第 16 篇（batch verify 的 top-1 位级

git reset --hard 之后先别哭：reflog 里存着你刚弄丢的那个分支周五 18:47，为了"清掉本地乱七八糟的改动"，一条 git reset --hard HEAD~3 敲下去，工位三秒后传来哀嚎：下午写的那两个提交没了。

后端 Web 实战：员工管理模块（多表关系 + 多表查询 + 分页查询 + 条件分页）大家好！上一篇我们完成了部门管理的增删改查，这一篇继续推进 Tlias 智能学习辅助系统的第二个模块——员工管理。从页面原型可以看到，查询员工列表时除了要展示员工基本信息，还要带出所属部门名称，数据横跨 dept 和 emp 两张表，这就牵出了今天的主线：

网页上答对、接口里答错：同一个知识库，差的不是模型是入口交付之后，我这边拿到过一类很有代表性的截图：同一句话，在对方自己系统的对话框里问，答案少了一段关键内容；我把这句话原样拿到网页上问一遍，是对的。

真实 flaky 18.3%，CI 报 0%，让 Agent 修测试，它删掉了被测的变量过去四天，有人在 GitHub 上把六个公开仓库一个一个打开读完。它们在做同一件事，把一个随机失败的门禁，处理成一个看起来稳定的门禁。六个里面，四个是 Agent 干的。

Bun v1.4.4 实测：2,025 个文件，bun fmt 2.6 秒跑完先给结论：Bun v1.4.4把 bun fmt、bun check、bun install、Bun.SQL 全塞进了一个补丁版本。我在自己机器上实测了前三项，官方基准一并列在下面。

Spring Data JPA高级特性详解定位：第 02 篇，讲透 Specification 动态查询、投影、自定义仓库实现与领域事件适用版本：Spring Data JPA 3.x（Hibernate 6.x）