登录成功，只能说明账号凭证通过了验证。后台页面、订单、文章、文件能不能访问，还得由授权规则继续判断。Symfony Security 把这些事情放进一套相对完整的机制里：用户从哪里加载、密码如何校验、哪些请求需要登录、具体资源能否被当前用户操作，都可以集中配置和复用。

可以把它理解成一组按线程分开的储物柜：柜子的编号由 ThreadLocal 对象决定，柜子属于当前线程。线程 A 放进去的数据，线程 B 看不到；即使两个线程操作的是同一个 ThreadLocal 对象，也不会读到对方的数据。

简介WPF 项目刚开始时，窗口、按钮和业务代码放在一起，开发速度很快： {代码...} 页面少时问题不明显。功能一多，代码后面通常会变成：一个窗口里塞着几十个按钮事件；View 直接创建服务和仓储；页面之间相互引用，改一个模块牵动多个窗口；业务逻辑只能通过启动 WPF 窗口测试；菜单、内容区、弹窗和模块加载没有统一规...

真正的微服务架构里，每个服务围绕清晰的业务能力组织，可以独立构建、部署和扩缩容；服务管理自己的业务规则和数据，通过网络协议协作。它带来的不是免费的弹性，而是一整套新的分布式问题：

Razor 不是一种新的 C# 语言，也不是单纯的 HTML 模板。它是一套把 C#、HTML 和标记语法组合起来的语法与编译机制，ASP.NET Core MVC、Razor Pages 和 Blazor 都会用到。

简介写 C# 时，new 一个对象很容易，但背后涉及 CLR 的对象分配、内存区域、GC 根、分代晋升和堆压缩。托管堆是 CLR 管理托管对象的主要内存区域。它解决了手动 malloc/free 容易出错的问题，但并不意味着内存问题自动消失：静态集合仍然引用对象，GC 就不能回收；短时间大量分配，会造成频繁 GC；大数组进入 LOH 后，反...

很多数据库教程停在“插入一条数据、查询一条数据”。真正开始写业务后，马上会遇到更多问题：字段怎么设计？数组怎么查？分页怎么写？索引到底有没有生效？应用代码如何安全地复用数据库连接？

简介线上 .NET 程序出现问题时，最麻烦的往往不是“报错了”，而是：进程内存一直涨，却不知道是哪类对象没有释放；CPU 飙到 100%，日志里只有几行普通请求记录；接口没有异常，但线程全部卡住；进程已经退出，只留下一个 Dump 文件；async/await 层层等待，普通调用栈看不出真正的阻塞点。这类问题需要直接查看 CLR 的运...

简介在 .NET 里，只要你开始接触这些场景：调用 Win32 API复用已有的 C/C++ 动态库对接系统底层能力或硬件驱动调用高性能原生库，例如压缩、图像、音视频、加密库处理句柄、指针、非托管内存你大概率都会走到一个关键能力： {代码...} 一句话先说透：P/Invoke 的本质，是让托管代码通过运行时提供的互操作机制，去调用非...

容器启动后，应用可能会创建日志、修改配置、生成 PID 文件，也可能把上传文件写进容器内部。docker diff 专门用来查看这些变化：列出容器创建以来，相对于原始镜像发生变化的文件和目录，并用 A、C、D 标记变化类型。

对象少时，手动 new 很直观。对象关系变复杂后，创建代码会慢慢蔓延到控制器、业务类和启动代码中：实现类换了，要改很多处；测试时想替换成内存仓储，也要一路修改构造函数。

简介业务方法里经常混着这些代码：记录日志、检查权限、统计耗时、开启事务、读写缓存、捕获异常。 {代码...} 方法少时还能接受，方法一多，横切逻辑就会到处复制。修改日志格式要改很多处，漏掉一次权限检查也很危险。动态代理提供了一层运行时生成的“外壳”：调用方拿到的仍然是原来的接口或类型，方法调用却会先经过代...

本文按 Zig 0.16.0 编写。这个版本的 AutoHashMap 和 StringHashMap 使用 init(allocator) 保存分配器，后续 put、getOrPut、deinit 等方法不再重复传入 allocator。旧教程中把 allocator 传给每次操作的写法，属于 unmanaged 形式。

处理数量不确定的数据时，固定长度数组很快就会遇到限制：文件有多少行并不确定，接口返回多少条记录也不确定，程序运行过程中产生多少个结果更无法提前写死。

很多语言把构建配置写成一堆声明：源码目录、编译参数、链接库、安装目录分别放在不同字段里。Zig 走了另一条路：build.zig 本身就是一个 Zig 程序。

Allocator 就是这套规则的入口。它不是一块内存，而是一组“申请、调整、释放内存”的操作，以及这些操作背后的上下文。换一个 Allocator，同一段业务代码就可以使用堆内存、栈上的固定缓冲区、Arena，甚至自定义内存池。

别把 Debug 和 Release 混为一谈：Zig Build Mode 全面解析编译同一份 Zig 代码时，Debug 和 ReleaseFast 可能得到完全不同的运行行为。Build Mode 不只是“要不要优化”的开关，还会影响：编译器优化程度；运行时安全检查；生成文件大小；编译速度；unreachable、整数溢出和数组越界等非法行为的处理方式；代码中通过 bui...

很多语言把编译期限制在常量折叠、宏或代码生成器上。Zig 更进一步：普通 Zig 函数、循环、条件判断、类型操作和校验逻辑，都可以在编译阶段执行。

别把错误当异常：Zig error set、error union 与 errdefer 实战很多语言把失败交给异常机制：函数执行到一半抛出异常，调用方再用 try/catch 接住。Zig 选择了另一条路线：错误是语言中的一种值，函数签名直接写出“可能失败”，调用方必须明确决定继续传播、提供默认值，还是按错误类型处理。这一套机制由几个部分组成： ...

函数不只是把几行代码起一个名字。在 Zig 里，函数签名还会直接说明参数类型、返回类型、是否可能失败、是否需要编译期参数，以及是否允许修改外部数据。

大括号可以创建新的作用域，也可以作为一个表达式产生结果；加上标签后，还能像一个小型的提前返回点，让多步计算保持在同一段代码里完成。while、for、switch 和 defer，也都和 block 有直接关系。

当一个值可能是整数、字符串或一组结构化数据时，union 可以把这些可能性组织成一个类型。多个成员共享同一块存储，同一时刻只有一个成员有效。

前端打包结果、静态 HTML、接口 Mock 数据、图片目录，很多时候只差一个 HTTP 服务就能正常运行。直接双击 index.html 得到的是 file:// 地址，而 fetch()、ES Module、路由回退等功能通常需要 http:// 环境。

别只把 switch 当成多路 if：Zig 模式匹配、状态机与 Tagged Union 实战很多语言里的 switch 只是把一串 if-else 换成了另一种写法。Zig 的 switch 更像一个带编译期检查的模式匹配工具：可以作为语句执行逻辑，也可以作为表达式返回值；枚举和错误集可以做穷尽检查；支持多个值合并和闭区间范围匹配；可以解构 Tagged U...

但 Zig 的 enum 不止是“几个整数常量”。它有强类型约束，可以和 switch 做穷尽检查，可以指定底层整数类型，可以定义方法，还能和 union 组合成携带不同数据的 Tagged Union。状态机、协议解析、命令分发和错误分类，都适合用这套能力表达。

在 Zig 里，struct 不只是把几个变量放在一起的“数据盒子”。字段、默认值、方法、嵌套类型、泛型、错误处理和内存布局，都可以围绕一个结构体组织起来。

*T、*[N]T、[*]T、[]T 只差几个符号，代表的能力却完全不同：有的只能指向一个值，有的可以移动，有的带长度，有的允许为空。类型写得准确，很多内存错误在编译阶段就会暴露；类型选错，代码即使能编译，也可能留下越界访问或悬空指针。

这样可以限制调用方不能直接 Add，但它只是一个只读视图。只要内部的 List<string> 还在变化，外部枚举到的内容就可能变化。

Spectre.Console.Cli 把命令行解析和 Spectre.Console 的终端呈现能力组合在一起，适合构建部署工具、文件处理工具、代码生成器、数据迁移工具和 .NET Global Tool。

如果所有参数都靠 args[0]、args[1] 手动判断，代码很快会遇到这些问题：参数顺序难以记忆，数字和文件路径需要手动转换，错误提示不统一，帮助信息还得另外编写。