登录成功立刻 401：Cookie Secure 陷阱
登录成功立刻 401：Cookie Secure 陷阱 项目：SGCC 智能服务控制台 · 学习记录 现象部署到服务器后第一次试登录，看到的是这样的体验： 输入邮箱 → 收到验证码 → 上传 auth.key → 提交 浏览器跳出登录页，地址栏短暂出现 /home 马上又被弹回 /login 手动改地址栏到 /work-order，页面能渲染出来 一点击列表里的任何东西 → 又被弹回 /login 后端日志里没有任何报错： 1INF event=login_success email=2521664384@qq.com 登录是成功的。但每次跳转都瞬间被踢出。 诡异之处：登录确实成功了，但用户像是「持有了一张看不见的票」——服务端认为他登过，浏览器表现得他没登过。 排查思路第一步：看 nginx 日志12"POST /api/auth/login HTTP/1.1" 200 77 ← 登录成功"GET /api/auth/check HTTP/1.1" 401 36 ← 紧接着 401 中间隔了不到 1 秒。登录...
Gitea 实例被批量注册攻击处理实录
Gitea 实例被批量注册攻击：一千多个垃圾账户的应急处理实录时间：2026年4月8日-9日事件：私人Gitea实例遭遇自动化垃圾注册攻击，被创建1000+恶意账户攻击特征：使用算法生成邮箱域名（elyquin.org、juxal.org、glinxy.com等）和仿真实姓名用户名（mackriley79、katharinaarchuleta91等） 一、发现异常执行日常维护时发现异常： 1docker exec -it --user git gitea bash -c "gitea admin user list" 输出显示用户数量异常增长，检查后发现： 正常用户：ID 1-5（管理员及团队成员） 垃圾账户：ID 8-1000+（批量注册的机器人账户） 命名规律：用户名长度均大于10字符，邮箱来自特定垃圾域名 二、攻击特征分析 特征 详情 邮箱模式 姓名+数字@子域名.主域名 典型样本 mackriley79@simu.elyquin.org、katharinaarchuleta91@seti.juxal.org 域名特点 算法生...
任务队列与单例模式思考
Python 单例模式深度解析：从任务队列的多实例问题谈起1. 问题的起源在开发 AssociationRuleTaskQueue（关联规则任务队列）时，我们遇到了一个关于“实例唯一性”的疑问： “我在运行 from core.task_queue import rule_task_queue 的时候，其实就会运行一次 rule_task_queue = AssociationRuleTaskQueue() 对吗？所以每一次导入都会实例化一次对吗？” 这个疑问触及了 Python 两个核心机制：模块导入机制 和 类实例化机制。本文将以此为切入点，深入解析 Python 的 __new__ 方法与单例模式（Singleton Pattern）。 2. Python 模块导入机制：天然的“单例”首先回答你的疑问：每一次导入并不会都实例化一次。 Python 的模块（Module）对象在整个解释器进程中是全局唯一的。当你执行 import core.task_queue 或 from core.task_queue import rule_task_queue 时，Python 内...
防火墙大乱斗：iptables、ufw、firewalld 到底是什么关系？
作为一个 Linux 用户，你肯定经历过这样的时刻：想开个 80 端口，搜到一条命令是 iptables -I INPUT -p tcp --dport 80 -j ACCEPT。换了台 Ubuntu 服务器，教程又让你用 ufw allow 80。到了 CentOS 7/8，系统告诉你 iptables 过时了，请用 firewall-cmd --add-port=80/tcp。 这时候你可能会想：为什么 Linux 有这么多防火墙？它们是竞争关系？替代关系？还是根本就是同一个东西换了层皮？ 今天我们就来把这团乱麻彻底理清楚。 一、 核心真相：它们都只是“遥控器”首先要揭露一个真相：iptables、ufw、firewalld，严格来说都不是真正的防火墙。 Linux 真正的防火墙藏在操作系统内核里，它的名字叫 Netfilter。 Netfilter (内核态)：它是 Linux 内核的一个框架，负责在网络协议栈中“抓包”、修改包、过滤包。它是真正的干活人，住在内核空间，普通用户接触不到。 用户态工具：iptables、ufw、firewalld 都是运行在用户...
再见 Conda？Python 极速包管理器 uv 上手指南
Python 的环境管理一直是个让开发者头秃的问题。 从最早的 pip + venv，到科学计算必备的 conda，再到后来追求项目隔离的 poetry 和 pdm，我们手里的工具越来越多，但困惑也越来越多： “Conda 解析依赖太慢了，一直在转圈圈。”“听说 Anaconda 公司改了协议，公司用要收费了？”“Poetry 很好用，但是安装依赖有时候卡很久。” 就在大家在这个泥潭里挣扎时，uv 横空出世。它号称是“Python 的 Cargo（Rust 的包管理器）”，主打一个字：快。 今天我们就来聊聊这个用 Rust 编写的 Python 包管理新星，看看它是否有资格终结这场“环境管理之战”。 一、 为什么要换掉 Conda？很多 Python 初学者（尤其是搞数据科学的）入行安装的第一个软件就是 Anaconda。但随着时间推移，Conda 的问题逐渐暴露： 慢：这是最大的槽点。当你安装一个复杂的库（比如 PyTorch）时，Conda 的依赖解析（Solving environment）能让你等到怀疑人生。 臃肿：Anaconda 预装了太多你根本用不到的库，占...
面试造航母：普通开发者真的需要担心“千万级并发”吗？
“如果有 1000 万并发，你的系统怎么设计？” 这大概是后端面试中最经典，也最让人无语的问题之一。 作为一个在中小厂摸爬滚打多年的普通开发者，我常常看着自己负责的系统——QPS（每秒查询率）峰值不到 50，日活几千人——陷入沉思：我这辈子真的能遇到千万级并发吗？ 今天我们就来戳破这个泡沫，聊聊并发的真相，以及作为普通开发者，我们真正应该关心什么。 一、 别被“并发”忽悠了首先，我们要厘清几个被混淆的概念。 1. 网页资源多 = 并发高？有人告诉你：“一个网页加载要请求 50 个图片、CSS、JS，如果有 1 万个人访问，那就是 50 万并发啊！” 这是典型的偷换概念。 CDN 的存在：现代 Web 开发，静态资源（图片、CSS、JS）通常都放在 CDN 上，根本不会打到你的后端服务器（API Server）。 浏览器限制：浏览器对同一个域名的并发连接数是有限制的（通常 6-8 个）。 长连接：HTTP/1.1 和 HTTP/2 复用了 TCP 连接。 所以，前端资源的请求量，跟后端服务的并发压力，完全是两码事。 2. 用户量大 = ...
PostgreSQL：数据库界的“瑞士军刀”，真的能取代 Redis 吗？
最近，技术圈里刮起了一股“反简化”的风潮，其中最响亮的口号之一就是：“你其实不需要 Redis，一个 PostgreSQL 就够了。” 作为一个习惯了 MySQL + Redis 黄金搭档的开发者，听到这话的第一反应通常是：“疯了吧？Redis 是内存数据库，PostgreSQL 是关系型数据库，这俩能是一回事？” 但当你深入了解 PostgreSQL（简称 PG）之后，你会发现它早已不是一个简单的“关系型数据库”了。它更像是一个无所不能的数据库平台。 今天我们就来聊聊这位“全能选手”，以及它是否真的有底气取代 Redis。 为什么大家都在谈论 PostgreSQL？在 MySQL 称霸 Web 开发的年代，PostgreSQL 常被贴上“学院派”、“配置复杂”的标签。但随着版本迭代，PG 凭借其强大的扩展能力（Extensions）和先进的特性，逐渐成为了架构师的心头好。 它支持： 关系型数据（标准的 SQL，比 MySQL 更严格更强大）。 JSON 文档（JSONB 类型，查询性能甚至超越 MongoDB）。 地理空间数据（PostGIS，地图应用的行业标准）。 全文检...
架构演变史：你以为的“前后端分离”可能只是冰山一角
作为一名后端开发者，你是否也有过这样的困惑： “前端把代码打包成一堆 HTML/CSS/JS 给我，我把它丢在我的 Nginx 或者静态目录里部署，这不就是以前的 MVC 吗？这也能叫前后端分离？” “隔壁组的前端自己在服务器上跑了个 Node.js 服务（React/Vue），然后调我的 Java/Python 接口，用户直接访问他们的服务，这才是真正的分离吧？” 其实，这两种模式都属于“前后端分离”，只是处于演变历史中的不同阶段，或者说是为了解决不同问题而诞生的架构模式。 今天，我们就来一场时空穿越，聊聊 Web 开发架构的前世今生，帮你彻底理清这些概念。 第一阶段：混沌初开 —— 传统的服务端渲染 (Classic SSR / MVC)在 2010 年以前（PHP、JSP、ASP.NET、早期的 Django/Rails 时代），Web 开发的主流是 服务端渲染 (Server-Side Rendering)。 工作模式 浏览器向服务器发送请求。 后端（PHP/Java/Python）接收...
显存去哪了？深度学习框架显存管理机制与多模型共存指南
在使用 MinerU、Stable Diffusion 或 LLM 本地部署时，我们经常会遇到一种“灵异现象”：模型明明跑完了，任务也结束了，但显存（VRAM）占用依然居高不下。如果有两个模型想在同一张显卡上轮流跑，经常会因为前一个模型“占着茅坑不拉屎”而导致后一个模型 OOM（Out Of Memory）。 为什么显存会“无休止”地扩张？为什么框架不愿意把显存还给操作系统？这背后其实是一套精心设计的“贪婪”机制。 今天我们就来扒一扒深度学习框架（以 PyTorch 为例，TensorFlow 同理）的显存管理底层逻辑，以及如何在单卡上优雅地运行多个模型。 一、 为什么显存“只吃不吐”？很多开发者会发现，Python 脚本运行过程中，显存占用往往是一条只增不减的曲线。这其实是因为框架内部实现了一个 Caching Allocator（缓存分配器）。 1. 昂贵的系统调用在 GPU 上分配内存（cudaMalloc）和释放内存（cudaFree）是系统级调用，这些操作非常“昂贵”，会强制 GPU 同步，打断计算流水线。 如果模型在推理过程中，每算一层网络就申请一次显存，算完就释放...
开发安全指北：ORM 防住了 SQL 注入，那“文件名注入”呢？
在现代 Web 开发中，ORM（对象关系映射）框架的普及极大地降低了 SQL 注入的风险。很多开发者（包括以前的我）因此产生了一种错觉：“只要我用了 SQLAlchemy 或 Django ORM，我的后端就是安全的。” 然而，现实往往会给你一记响亮的耳光。最近我在做安全排查时被告知存在“文件注入”和“文件名注入”风险。这让我意识到，Web 安全远不止 SQL 注入那么简单。 今天我们就来聊聊，除了 SQL 注入，开发过程中还有哪些容易被忽视的“注入”陷阱，以及我们该如何防御。 一、 文件名注入与路径遍历 (Path Traversal)这是很多初级甚至中级开发者最容易踩的坑。 1. 场景还原假设你有一个上传头像的功能，后端代码可能是这样写的： 1234567import osdef upload_avatar(file): # 直接使用用户上传的文件名 filename = file.filename save_path = os.path.join('/var/www/uploads', filename) file.save(...
