pnpm Monorepo 跨环境构建失败排查实录
pnpm Monorepo 跨环境构建失败排查实录：一个 Zod 类型幽灵导致的深坑背景项目 P001-OPC 是一个基于 Next.js 15 + React 19 的企业级 Monorepo 应用，使用 pnpm 管理依赖，技术栈包括： 构建：pnpm 10.14 + Turbo 2.5.6 框架：Next.js 15.5.0 / React 19.1.1 / TypeScript 5.9.2 文档：Fumadocs 15.7.1 + @content-collections/core 0.11.0 验证：Zod 3.24+ 数据库：Prisma 6.14.0 本地开发和构建一切正常，但将代码部署到服务器执行 pnpm build 时，反复出现类型错误。 现象本地 pnpm build 完美通过，服务器上同样的代码、同样执行 pnpm install，构建时报错： 12./app/(marketing)/[locale]/docs/[[...path]]/page.tsx:26:19Type error: Property 'to...
登录成功立刻 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 秒。登录...
为什么部署里有一个 build 容器还有一个 api 容器
为什么部署里有一个 build 容器还有一个 api 容器 项目：SGCC 智能服务控制台 · 学习记录 起因我重构完部署后，看着 docker-compose.yaml 里的服务列表犯嘀咕： 123456services: db # 数据库 frontend-build # ? api # ? nginx # 反向代理 + 静态托管 backend # Python 数据管线 「我不就是部署个前端嘛，为什么还要有一个 api 容器？前端应该 build 完用 nginx 反代 index.html 就够了啊？」 ——这是我那天的原话。后面被纠正了我才意识到：「前端」这个词在我脑子里和实际意义不一致。 下面把这件事彻底理清楚。 概念修正：「前端」≠「整个网站」浏览器里能跑什么、不能跑什么能跑的： HTML / CSS / JS（这些都是死的文本文件） 渲染界面、响应点击 调 fetch() 给某个 URL 发请求 不能跑的： 连数据...
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）接收...
