CodeSky 代码之空

使用模型：为了省钱，用的本地部署的模型

本来想直接把 Coze Studio 和 Dify 都写完的，由于都写完工期太长，可能导致吃屎都赶不上热乎的，所以先发 Coze Studio

Coze Studio

基于 v0.2.6编写，截止 2025-08，后续发布与本文无关。（比如 Chatflow 目前处于 beta 版本）

在 Web 开发中，身份认证是一个很常见的诉求，而平时设计中并没有好好研究整体的 Auth 体系，今天就从头开始研究一下 Auth 这个东西。

MDN 对 HTTP Auth 有所总结：

RFC 7235 定义了一个 HTTP 身份验证框架，服务器可以用来质询（challenge）客户端的请求，客户端则可以提供身份验证凭据。

质询与响应的工作流程如下：

1. 服务器端向客户端返回 401（Unauthorized，未被授权的）响应状态码，并在 WWW-Authenticate 响应标头提供如何进行验证的信息，其中至少包含有一种质询方式。
2. 之后，想要使用服务器对自己身份进行验证的客户端，可以通过包含凭据的 Authorization 请求标头进行验证。
3. 通常，客户端会向用户显示密码提示，然后发送包含正确的 Authorization 标头的请求。

而大部分 HTTP 验证都遵循这一流程，只是加密算法、验证实现可能有所区别。

在 Redis 的常见应用中，分布式锁是一个老生常谈的问题，本文主要讲讲怎么去实现一个分布式锁（最近真·写了不少 Lua 脚本）。

加锁

对于加锁操作，理论上应该是：

1. 尝试加锁，如果成功，则记录锁，并且返回 true
2. 如果失败，则不更新锁，返回 false

限流也是一个系统中老生常谈的话题了，因为资源不是无限的，因此系统总会达到一个瓶颈，我们不可能接受无限的流量直到系统崩溃，于是也就有了限流策略。

多少流量该限流

一般来说，我们有几种方法可以来对系统进行评估：

距离上一次更新已经超过一个月了，是月更博主对不起大家了！

主要是因为之前有一阵子业务比较忙，因此一直在加班，没有空看其他的东西（又不愿意牺牲打游戏和看剧的时间），最近一有时间就在写 Demo，这几天刚写完，才能更新这篇文章。

背景故事

这个需求也是在我们业务落地过程中衍生出来的，因此先来说说之前一阵子忙的东西吧。

在公司内做的服务因为有各种基建的加持，所以想要实现一些功能很容易，比如说标题写的东西，或者是 binlog 订阅消费；但是在 to B 私有化部署的场景下，客户机千奇百怪，就要求我们用尽可能少的依赖和简单的部署架构进行实现，肯定也不会有公司里这么多花里胡哨的依赖。

为此简化了不少架构和功能，牺牲了不少体验之后才给接入我们基建的用户怼上一个版本。

而其中一个诉求就是我们的功能需要（Nice to have）订阅过期键并广播给订阅用户。

好久没有更新博客了，稍微写个几行吧……不然都快不会写东西了 emmm。

众所周知，导出表格是中后台一个非常普遍的需求，而 Golang 官方库中就提供了 encoding/csv