博客
关于代码、AI 和产品的思考和笔记。
Python 并发编程完全指南
Python 并发编程完全指南> 定位：面向中高级 Python 开发者的并发/并行知识库 > 前置知识：熟悉 Python 基础语法、装饰器、上下文管理器 > 阅读收益：掌握 Python 所有并发方案的底层原理、选型标准和生产级避坑指南--- 第一章：核心概念与术语 1.1 并发（Concurrency）vs 并行（Parallelism）| 概念 | 定义 | 硬件要求 ||-----
Pandas 系统整理
Pandas 系统整理适用场景：结构化表格数据的 ETL 及常规数据分析。阅读方式：先看全景图建立心智模型 → 快速上手跑通全流程 → 按需深入分层详解。--- 一、数据流全景图mermaidflowchart LR %% 定义样式 classDef io fill:fff3e0,stroke:e65100,stroke-width:2px classDef core fill
Spark SQL 用法手册
Spark SQL 用法手册> 适用场景：日常写 Spark SQL 多、PySpark 少的数据开发岗位。纯 SQL 语法、带测试数据、每类方法说明用法并展示运行效果。>> 环境：Spark 3.x，使用 spark.sql() 执行。以下所有示例在 Spark Thrift Server 或 spark-sql CLI 中也可直接运行。 优秀资料分享[Spark SQL 函数分类导航](ht
Spark SQL 内核精解：三层架构视角下的全链路拆解
Spark SQL 内核精解：三层架构视角下的全链路拆解> 适用读者：有一定大数据开发经验，但希望深入理解 Spark SQL 内部原理的数据工程师、数据平台开发人员。>> 阅读方式：本文采用逐层递进的结构——每章只引入该层的新概念并配模块图，最后一章才拼出完整全景图。建议顺序阅读，不要跳读。>> 全文线索：跟随一条 SELECT DISTINCT(query) FROM query_table
统计建模-假设检验和回归分析
假设检验 和 回归分析 假设检验：判断差异是不是"真的" 核心问题你观察到 CTR 从 12% 变成 13%，这1%的提升到底是排序策略真的有效，还是纯粹随机波动？任何指标天天都在波动，哪怕什么都没变，今天12.3%明天11.8%都很正常。假设检验要解决的就是：怎么判断"看到的差异"够不够大，大到不能用随机波动解释。 为什么能做到——背后的逻辑链 第一步：假设"什么都没变"（零假设）零假设 H
Docker 深度指南：从部署博客到理解容器
Docker 深度指南：从部署博客到理解容器> 这不是一本"命令大全"，而是一条从真实困境出发、逐层剥开的认知路径。> 每个概念都在你问"为什么"的时候才出现，每个流程图都试图把一个抽象机制说清楚。--- 引子：我的博客，三个环境的三种命运你写好了一个博客——Python + FastAPI，本地 uvicorn app.main:app 跑得飞起。准备上线了：开发机 (Python 3.12)
反爬虫与安全防护体系 — 设计手记
反爬虫与安全防护体系 — 设计手记> 从一次自主发起的防护评估开始，到逐条分析威胁、否定不合适的方案、落地真正有效的防护，最终形成一个分层反爬体系。本文档完整记录了决策过程、取舍理由和架构设计。--- 一、为什么需要反爬——威胁分析在实施任何防护前，需要先清点被保护对象的资产价值。不同资源被爬取的后果差异很大，统一防护等级会导致过度设计或防护不足。 1.1 资源分级| 资源
部署数据丢失事故复盘
部署数据丢失事故复盘> 一次 deploy-update.sh 执行后博客文章"全部消失"的排查与修复记录。>> 从现象到根因一共四层下钻：确认挂载 → 发现两份 db → 路径不匹配 → DATABASE_URL 格式错误。每一层的排查命令和判断依据都有记录，可作为类似问题的快速定位参考。--- 一、前置背景 1.1 这个项目是怎么部署的项目使用 Docker 部署，有两套部署脚本：deplo
多路径写入一致性：从一次 Debug 到系统性防御
多路径写入一致性：从一次 Debug 到系统性防御 写在前面这不是一篇通用的技术教程，而是一次真实 Debug 的完整复盘。问题本身很简单——"博客分类筛选不工作"——但往下挖了四层才发现，表象各异的四个 Bug 其实指向同一个设计缺陷。这个缺陷从项目的第一行代码就埋下了，后续每次加功能都在上面打补丁，直到补丁本身变成了问题的一部分。我想通过这个案例说清楚三件事：1. 数据一致性不是靠修 Bug