MySQL 事务锁与 MVCC：InnoDB 诊断表与巡检 SQL 备忘
线上出现「语句一直转圈」「连接数暴涨」时，往往需要同时看：谁在跑、等了什么锁、谁在挡路。InnoDB 把事务与锁的信息暴露在系统表（及 8.0 起的 Performance Schema）里，再结合 MVCC 能理解「为什么同一行在不同会话里看到不同版本」。下文与站内 MySQL 进阶：架构与存储 可对照阅读。 MySQL 主版本差异（与本文相关）自 MySQL 8.0.1 起，information_schema 中的 INNODB_LOCKS、INNODB_LOCK_WAITS 已移除，锁与等待改查 performance_schema.data_locks、data_lock_waits（见官方手册）。INNODB_TRX 在 8.0 仍位于 information_schema。 版本线 事务 锁与等待 锁等待诊断 5.5–5.7 information_schema.innodb_trx innodb_locks、innodb_lock_waits 下文「5.5–5.7」脚本可直接用（权限与 sql_mode 另说） 8.0+ information_s...
Python 工匠：工程实践与代码质量备忘（2026）
把零散笔记整理成一篇「能随手翻开」的备忘：它不替代官方文档，但能在你搭新项目、加 CI、写评审意见或排查异步问题时，少绕一圈弯路。依赖与锁文件我单独写过一篇更细的梳理，见文末内链；这里侧重工具链、结构、可读性与运行时习惯。 读完你可以带走：一条可复制的本地检查命令思路、导入与目录的朴素规则、评审 README 时的检查项，以及 asyncio 里 await 顺序与 gather 的真实语义。 包管理与「项目长什么样」 工具地图：Anna-Lena Popkes 的 An unbiased evaluation of environment management and packaging tools 用文氏图把「环境 / 包 / Python 版本 / 构建 / 发布」拆开，适合选型时对照。 高性能安装器：uv 在解析与安装上很快，适合新项目和 CI。 目录结构：Matt 的 python-project-structure-2024 讨论了「src 布局、测试与打包」等常见取舍。 若你希望从 pyproject、锁文件到 uv 工作流...
SEO入门指南（2026版）：从零开始，简单实用
搜索引擎优化（Search Engine Optimization，SEO）简单说，就是让你的网站在百度、Google 等搜索引擎里更容易被找到、排名更高，从而带来免费流量。不是作弊，而是让网站对用户和搜索引擎都「友好」。 2026 年，SEO 已经不是「塞关键词」那么简单。Google 等搜索引擎更看重对用户的真正帮助（People-First Content）、真实经验（E-E-A-T）和良好体验（速度、移动友好）。AI 搜索（如 Google AI Overviews）越来越常见，很多人搜索后直接看到答案、不必点击网站——所以内容必须高质量、有独特性，才能被引用或吸引点击。 新手心态：SEO 是长期游戏（常见几个月到一年见效），别追求速成黑帽（作弊手法），会被惩罚。重点是白帽 SEO：对用户好，自然排名才稳。 一、多语言 SEO 的核心价值如果你想把网站推向全球，多语言支持很有用。 市场扩展：英文内容只覆盖约一部分互联网用户，多语言可扩大覆盖。非英语地区，本地语言内容排名往往更好。 用户体验：母语用户停留时间更长、跳出率更低、转化率更高（很多人只在母语网站购物）。 实际...
Just for Survive：一个普通程序员的Linux梦
我是一个普通程序员，每天敲代码不是为了改变世界，只是为了活下去。今天下班后，我在出租屋里翻完了《Just for Fun》——Linus Torvalds的自传。书里他说，人生有三个阶段：survival（生存）、social order（社会秩序）、entertainment（娱乐）。Linux就是他“just for fun”搞出来的。可我读着读着，眼泪差点掉下来。因为在我们这儿，从来没有“just for fun”这回事，只有“just for survive”。 早上六点半闹钟响，我爬起来挤地铁。车厢里全是和我一样黑眼圈的码农。九点打卡，打开电脑，先看老板昨晚十一点发来的消息： 老板： 这个功能今天必须上线，不然KPI扣分，奖金没了。 我不敢回「今天做不完」，只能埋头敲代码。午饭是外卖十块钱的盒饭，边吃边改Bug。晚上十点半，产品经理又发来微信： 产品经理： 用户反馈卡顿，再优化一下。 我： 好。 其实心里在骂娘。回到家已经十一点半，房贷、车贷、父母养老、孩子上学……每行代码后面都是“just for survive”四个大字。 Linus小时候呢？爷爷给他买...
AI时代，程序员的软技能发展：从敲代码到指挥AI、经营自己
2026年4月，晚上十一点多，我坐在北京租的这间小一居里，空调嗡嗡响着，屏幕上又是Claude甩出来的一堆代码。我盯着看了二十多分钟，叹了口气：逻辑看着还行，但业务那边上次说的几个关键点又对不上，边缘case还漏了好几个。以前我自己从零敲一个功能，跑通了还能在心里小小得意一下，现在呢？大部分时间都花在给AI擦屁股、修bug、然后跟产品解释为什么这个方案不能直接上。 说实话，心里挺不是滋味的。翻出那本《软技能：代码之外的生存指南》的旧笔记，本来想找点方向，结果里面的话一句句戳得我更清醒了。作者说要把自己当成一家一人企业，别只当打工仔；要专业化，要学会跟人打交道，生产力得管好，最重要的——身体才是本钱。这些在AI时代，读起来像在说我这种35岁左右的普通程序员。 这两年国内互联网行业变化太快了。AI把基础代码、CRUD、套框架这些活儿干得飞快，很多公司已经默认一大半代码是AI生成的。以前招应届生干基础开发，现在好多部门直接不招了。35岁这个坎儿也越来越明显，上有老下有小，房贷车贷压着，薪资要求又高，企业一降本增效，就容易被优化。我有个朋友去年刚过35，被大厂“优化”了，投了几个月简历，...
我们这里技术真有好的 Leader 吗，还是企业的「黑手套」？
读完陈皓老师的这些笔记，我坐在出租屋里，电脑屏幕还亮着，眼睛干涩得发疼，好半天都没法往下滚动页面。心里像被什么东西堵住了，又酸又闷。 我就是一个最普通的打工人，在国内一家不算大的互联网公司干了七年多。从入职那天起，我就天天写CRUD、修线上bug、接产品临时改的需求、赶半夜上线。从来没带过团队，连个小组长都没混上。每天早上9点半打卡，晚上10点多才能走，周末经常一个电话就被叫回去“救火”。我早就认命了——“码农”嘛，不就是干体力活的吗？技术再好又怎样，升职加薪靠的是业务和销售，我只要把代码跑通、别出大事故就行了。加班、996、凌晨三点还在调试，我都习惯了，以为这就是普通程序员的命。 可今天读完《何为技术领导力》《如何拥有技术领导力》《如何成为一个大家愿意追随的Leader》这几篇，我突然觉得自己这些年活得特别可悲，也特别可笑。 最戳我心窝子的，是他那张Boss和Leader的对比表。Boss是“给我上”，Leader是“跟我上”；Boss制造畏惧，Leader制造热情；Boss收割成绩，Leader给予成绩……我遇到的那些上级，几乎全是前者。他们在周会上拍桌子吼“这个需求明天必须...
前端打包技术发展：Webpack、Vite、Rspack 与 Turbopack 流程对比（2026）
前端打包（bundling / building）在不同工具里的核心流程差异很大，主要体现在**开发环境（Dev）与生产环境（Prod）**如何处理模块。下面按 2026 年常见栈（Webpack、Vite（含 Rolldown）、Rspack、Turbopack 等）做流程对比，便于你按项目阶段选型。 Webpack / Rspack：传统 Bundle-First两者架构最接近：Rspack 是用 Rust 重写的 Webpack 兼容实现，流程几乎一致，整体更快。 核心流程（Dev 与 Prod 类似，偏全量打包） 入口扫描（Entry）：从 entry 出发，解析 import / require。 依赖图（Dependency Graph）：静态分析全项目，形成模块树（含子依赖）。 模块转换（Loaders / Rules）：按文件类型走 loader（如 ts-loader、css-loader、babel-loader）；Rspack 侧常用内置 SWC 并行加速。 优化（Optimization）：Tree Shaking、...
前端包管理机制笔记：npm、Yarn、pnpm、PnP 与 Bun 的技术权衡（2026）
选包管理器时，表面是「谁更快」，底层其实是 Node 怎样解析模块、依赖怎样落到磁盘。这篇把几条主流路线串成一条脉络：各自解决什么、留下什么坑，以及和「模块解析」这条硬约束怎么博弈。读完你能快速对齐术语，并在新仓库里做出有理由的默认选择。 若你还关心锁文件、可复现安装在另一条语言里怎么落地，可与站内 2026 年 Python 包管理与依赖选择 对照；CI 里「装依赖再构建」的套路则与 GitHub Actions + Hexo 博客自动部署、全栈开发技术选型：Nuxt Nitro 与 Python 后端如何取舍 同属一类工程习惯。 读完你能带走： Hoisting（依赖提升） 与 幻影依赖 为什么总是一起被提起。 pnpm 的内容寻址、node_modules/.pnpm 与「严格依赖」在行为上差在哪。 Yarn PnP 与 Bun 各自换掉的是哪一层，迁移成本大致有多高。 npm（2010–至今）：最早的「简单粗暴」设计带来的系统性问题核心技术架构 node_modules 扁平结构 + Hoisting（依赖提升）：安装时，npm 会把依赖（含子依赖）尽量「提升」到根 ...
前端是什么（2026 年最新版笔记）
图：前端技能树 / Roadmap 示意（个人笔记整理） 我们每天都在上网，我们上网上的是什么？最简单的就是看图片、视频、文字，这些在计算机中统称为超文本（Hypertext）。访问一个网页，其实可以分为两个部分：前端（用户可见的交互前台）和后端（服务器逻辑）。 本笔记专注前端部分，帮助新手从零建立完整认知。 浏览网页到底做了什么？ 图：在浏览器中输入网址后的完整流程（手绘） 当你在浏览器地址栏输入一个网址并回车后，到底发生了什么？ 这张手绘大图（非常适合新手）完整展示了整个流程：DNS 解析 → TCP 连接 → HTTP 请求 → 服务器响应 → 浏览器内部解析（HTML/CSS/JS）→ DOM/CSSOM → Render Tree → Layout → Painting → 最终显示。 浏览器内核（Rendering Engine）负责把网页代码转化为可见页面。2026 年主流内核： Blink（Chromium）：Chrome、Edge（新版）、Opera 等（占据 70%+ 市场） Gecko：Firefox WebKit...
后端是什么：2026 学习笔记（HTTP · I/O · API · WSGI · 数据库）
面向初学与回顾的一份结构化笔记：从前后端分工、HTTP 与 I/O，到 REST / GraphQL / RPC 等接口设计风格，再到 Python 的 WSGI/ASGI、多语言「应用—服务器」边界，以及数据库访问方式与工程实践。 学习路径可参考 roadmap.sh/backend（语言 → Git → 数据库 → API → 测试 → 容器化 → 微服务 → Observability）。 前端与后端：为什么底层更「稳」？典型 前后端分离 架构下：浏览器或 App 中的 Frontend 负责界面与交互；运行在服务器侧的 Backend 负责业务规则、数据与安全。双方通过 HTTP(S) 交换数据（常见为 JSON），形态仍是 请求—响应。 图：Frontend / Backend 职责划分 维度 Frontend（前端） Backend（后端） 关注点 界面、交互、渲染与客户端状态 业务规则、持久化、安全、性能与伸缩 运行环境 浏览器、移动端宿主（WebView 等） 服务器、容器或 Serve...