欢迎来到 W10N 的博客

vue basic Vue 3 npm init vue@latest 构建工具链 Vue 3 官方脚手架从 Vue CLI（基于 Webpack）切换到了 Vite。 工具分层 层次 Vue CLI 时代 Vite 时代 工具链 Vue CLI + Webpack Vite 转译器 Babel esbuild 打包器 Webpack Rollup（生产） 压缩 Terser esbuild（默认） Babel vs esbuild 两者都是 JS 转译器（Transpiler），核心职责相同：把现代 JS/TS/JSX 语法转换成目标环境能运行的 JS。 Babel esbuild 实现语言 JavaScript Go 速度 慢 快 10-100x 可扩展性 插件生态极其丰富 插件有限 功能边界 只转译 转译 + 打包都能做 适合场景 需要复杂插件、polyfill 追求速度的现代项目 Rollup Rollup 是一个 JS 模块打包器（Bundler），解决的核心问题是：把多个 JS 模块文件合并成一个（或少数几个）输出文件。 ...

解决的问题 1. 离线体验 传统 Web 应用断网即不可用。Service Worker 可拦截网络请求，从缓存中返回资源，让应用在无网络时仍能运行。 2. 网络性能 可缓存静态资源（HTML、CSS、JS、图片），后续请求直接走缓存，减少网络延迟，加快页面加载速度。 3. 推送通知（Push Notifications） 即使页面未打开，Service Worker 也能在后台接收服务器推送的消息并展示通知。 4. 后台同步（Background Sync） 当用户在离线状态下提交表单或操作时，Service Worker 可在网络恢复后自动重试，保证数据最终被发送到服务器。 5. 独立于页面生命周期 它是独立于页面的后台进程，页面关闭后仍可运行，适合处理跨页面共享的复杂逻辑。 核心本质：Service Worker 是一个可编程的网络代理，让开发者能完全控制"请求如何被响应"，这是 Web 平台此前缺失的能力。 概述 Service Worker 是浏览器在后台独立于网页运行的脚本，本质上充当 Web 应用程序、浏览器与网络之间的代理服务器。 是一种 JavaScript Worker，无法直接访问 DOM 通过响应 postMessage 接口发送的消息与页面通信 不用时会被中止，下次有需要时重启——不能依赖全局状态，持久数据应使用 IndexedDB 广泛使用 Promise 是浏览器中的独立进程（非内核线程），注册后可被多个页面共用，页面关闭后不会销毁 Chrome 调试 chrome://inspect/#service-workers chrome://serviceworker-internals 参考 https://juejin.im/post/6844903613270081543

vhost（虚拟主机） nginx 中每个 server {} 块就是一个虚拟主机（vhost，Virtual Host），同一台服务器上可以配置多个 server {} 块，让 nginx 同时托管多个网站或服务。 nginx 收到请求后，依次匹配 listen（端口/IP）和 server_name（域名），找到对应的 server {} 块处理请求。如果没有匹配项，则使用第一个定义的 server 或标记了 default_server 的块。 基于域名（最常用） server { listen 80; server_name example.com; root /var/www/example; } server { listen 80; server_name another.com; root /var/www/another; } 基于端口 server { listen 8080; server_name localhost; } server { listen 9090; server_name localhost; } 基于 IP server { listen 192.168.1.1:80; } server { listen 192.168.1.2:80; } nginx basic, command # Do not run, just test the configuration file. sudo nginx -t nginx -s signal # stop — fast shutdown # quit — graceful shutdown # reload — reloading the configuration file # reopen — reopening the log files almalinux install nginx sudo dnf update -y sudo dnf install nginx -y sudo systemctl enable --now nginx # install # nerdctl nerdctl run -d \ --name nginx \ --restart=always \ -p 80:80 \ -p 443:443 \ -v nginx-config:/etc/nginx \ -v nginx-www:/var/www \ -v /etc/letsencrypt:/etc/letsencrypt \ -v /etc/localtime:/etc/localtime:ro \ nginx:1.29.1 # docker docker run -d \ --name nginx \ --restart=always \ -p 80:80 \ -p 443:443 \ -v nginx-config:/etc/nginx \ -v nginx-www:/var/www \ -v /etc/letsencrypt:/etc/letsencrypt \ -v /etc/localtime:/etc/localtime:ro \ nginx:1.27.2 docker run -d \ --name nginx \ --restart=always \ -p 80:80 \ -p 443:443 \ -v nginx-config:/etc/nginx \ -v nginx-www:/var/www \ -v /etc/localtime:/etc/localtime:ro \ nginx:1.27.2 # podman podman run -d \ --name nginx \ -p 80:80 \ -p 443:443 \ -p 1022:1022 \ -v nginx-config:/etc/nginx \ -v nginx-www:/var/www \ -v nginx-cert:/etc/letsencrypt \ -v /etc/localtime:/etc/localtime:ro \ nginx:1.27.2 # nginx config text docker run --name nginx-config-test --rm -t -a stdout -v nginx-conf:/etc/nginx:ro nginx nginx -c /etc/nginx/nginx.conf -t # archlinux, mainline branch: new features, updates, bugfixes sudo pacman -S nginx-mainline # start sudo systemctl enable --now nginx # restart kill -HUP pid #stop kill -s QUIT 1628 文件下载 server { listen 8088; location /download/images { alias /home/net-files/images; # 我在这个路径下放了一张图片: fei_ji.jpg } } 下载 curl "http://my_ip_address:8088/download/images/fei_ji.jpg" > test.jpg ———————————————— 版权声明: 本文为CSDN博主「tomeasure」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接: https://blog.csdn.net/qq_29695701/article/details/86491331

nerdctl nerdctl 是 containerd 的命令行客户端工具，它提供了与 Docker CLI 兼容的用户体验。 什么是 nerdctl containerd 的 CLI 工具：nerdctl 全称是 “non-enterprise control”（或 containerd ctl） Docker 兼容：命令语法与 docker 命令高度兼容，降低学习成本 CNCF 项目：由 containerd 社区开发和维护 功能丰富：支持 Docker 不支持的一些高级功能 主要特性 1. Docker 兼容性 nerdctl 的命令与 docker 几乎完全兼容，可以无缝切换： # Docker 命令 docker run -d -p 80:80 nginx docker ps docker images docker build -t myapp . # nerdctl 命令（完全相同） nerdctl run -d -p 80:80 nginx nerdctl ps nerdctl images nerdctl build -t myapp . 2. 增强功能 nerdctl 支持一些 Docker 不支持的高级特性： ...

什么是 OpenTofu OpenTofu 是 Terraform 的开源分支，用于以声明式的方式管理云基础设施（IaC，Infrastructure as Code）。 与 AWS CLI 的区别： OpenTofu AWS CLI 方式 声明式（描述终态） 命令式（执行具体操作） 状态管理 有 state 文件，追踪资源状态 无状态 典型场景 创建/销毁一整套基础设施 查询、临时操作 OpenTofu 和 AWS CLI 都直接调用 AWS API，不存在封装关系。 核心概念 Provider Provider 是 OpenTofu 操作各家云服务的插件，tofu init 时自动下载。 required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } Resource vs Data Source resource — 创建资源（EC2、VPC、安全组等） data — 查询已有信息，不创建资源 # 查询最新的 Amazon Linux 2023 AMI（不创建资源） data "aws_ami" "al2023" { most_recent = true owners = ["137112412989"] filter { name = "name" values = ["al2023-ami-2023.*-x86_64"] } } # 创建 EC2 实例（使用上面查到的 AMI ID） resource "aws_instance" "server" { ami = data.aws_ami.al2023.id instance_type = "t2.nano" } Variables 变量分两个文件： ...

MFA（多因素认证） MFA（Multi-Factor Authentication）是在密码之外再加一层验证，防止密码泄露后账户被盗。 YubiKey 5C 支持 FIDO2/WebAuthn 协议，可作为硬件 MFA 设备使用，比手机 TOTP App 更安全。 常见 MFA 类型对比： 类型 示例 说明 硬件 FIDO2/WebAuthn YubiKey 5C 物理密钥，最安全 虚拟 TOTP Google Authenticator、Authy 手机 App 生成 6 位码 硬件 TOTP Gemalto 等老设备 专用硬件令牌 在 AWS 上绑定 YubiKey IAM → 用户 → 安全凭证 → 分配 MFA 设备 → 选择"安全密钥（FIDO）" → 按提示触碰 YubiKey 完成注册。 Root 用户和 IAM admin 用户建议各自绑定 MFA。 yubikey HMAC-SHA1 challenge-response YubiKey 4 可以同时工作在三种模式: OTP mode: 作为键盘设备 (HID) : Yubico OTP, ...

用户管理最佳实践 AWS 官方推荐：日常操作不使用 root 用户，改用 IAM 用户。 Root 用户 只用于以下场景，用完即退出： 创建 AWS 账户 设置账单和账户信息 创建第一个 IAM admin 用户 建议为 root 用户开启 MFA，日常锁起来不用。 IAM Admin 用户（日常使用） 对于个人用户，创建一个附加 AdministratorAccess 策略的 IAM 用户即可满足绝大多数需求。 AdministratorAccess 几乎等同于 root 权限，但不包括账单管理和关闭账户，日常管理 EC2、S3、RDS 等资源完全够用。 创建步骤： 以 root 登录 → IAM → 创建用户（如 admin） 附加托管策略：AdministratorAccess 为该用户开启 MFA 创建 Access Key 用于 CLI 之后退出 root，以后只用 admin 用户登录控制台和操作 CLI。 常用命令 查看所有区域的资源: ec2 > 左侧菜单 > AWS Global View # 配置 CLI（使用 IAM admin 用户的 Access Key） aws configure # S3 aws s3 ls s3://obsidian-w10n aws s3 cp foobar s3://obsidian-w10n https://aws.amazon.com/cli/ ...

Mermaid：VS Code 内置替代方案 Mermaid 是最佳替代方案，VS Code 的 Markdown 预览内置支持，无需扩展或服务器。直接在 Markdown 中写 ```mermaid 代码块，按 Ctrl+Shift+V 打开预览即可看到渲染结果。 功能 PlantUML Mermaid VS Code 原生支持 需要 Java + 扩展 内置 GitHub 渲染 不支持 支持 语法 更强大 更简洁 离线使用 需要 graphviz 完全离线 序列图 sequenceDiagram Alice->>Bob: Authentication Request Bob-->>Alice: Authentication Response Alice->>Bob: Another authentication Request Alice<<--Bob: Another authentication Response 类图 classDiagram class Animal { +String name } class Duck { +quack() } Animal <|-- Duck 活动图 / 流程图 flowchart TD start([start]) stop([stop]) decision{foo?} start --> decision decision -->|yes| process0[process0] decision -->|no| process1[process1] process0 --> stop process1 --> stop 状态图 stateDiagram-v2 [*] --> State1 State1 --> State2 State2 --> [*] 思维导图 mindmap root((Debian)) Ubuntu Linux Mint Kubuntu Lubuntu LMDE SteamOS Raspbian plantuml, puml UML 序列图, Sequence Diagram 用例图, Use Case Diagram 类图, Class Diagram 对象图, Object Diagram 活动图, Activity Diagram 组件图, Component Diagram 部署图, Deployment Diagram 状态图, State Diagram 时序图, Timing Diagram 非 UML 图 架构图, Archimate diagram UML 图 时序图, Sequence Diagram @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response Alice ->> Bob: async msg @enduml 类图, Class Diagram @startuml skinparam classFontColor red class Foo note left: parent class Bar Bar : String field0 Bar : String method0() Foo<|--Bar note left: child abstract class Abstract0 Foo--|>Abstract0 interface Interface0 ' 注意, 接口名和冒号之间必须用空格分隔 Interface0 : void method0() class Class0{ - private_field_0 } @enduml @startuml skinparam class { BackgroundColor Lightblue ArrowColor #0ACF97 BorderColor #d5d5d5 } skinparam stereotypeCBackgroundColor YellowGreen Class101 <|.. Class102 @enduml 活动图, Activity Diagram @startuml !theme plain start if (foo?) then (yes) :process0; else (no) :process1; endif stop @enduml 组件图, Component Diagram 别名后面可以标注颜色 修改线和箭头的颜色 文字颜色 语法 # 把组件显示成普通矩形 skinparam componentStyle rectangle # 组件间横向距离 skinparam nodesep 10 # 组件间纵向距离 skinparam ranksep 10 @startuml skinparam componentStyle rectangle skinparam nodesep 10 skinparam ranksep 10 skinparam ParticipantFontColor #A9DCDF ' comments line starts by single quote, 注释 [First component] [Another component] as Comp2 component Comp3 component [Last\ncomponent] as Comp4 [component0] as c0 #ff0000 [<color:#ff0000>component1</color>] as c1 [component2] as c2 [component3] as c3 [component4] as c4 c0 -- c1 c0-[#00ff00]-c2 c1--c3 c0--c3 c2--c4 note left of c0 note0 end note @enduml 部署图, Deployment Diagram @startuml circle 1 circle 2 circle 3 agent 4 1 -- 2 1 -- 3 1 -- 4 queue 5 4 -right- 5 5 -right-2 @enduml 状态图, State Diagram @startuml [*] --> State1 State1 --> [*] State1 : this is a string State1 : this is another string State1 -> State2 State2 --> [*] @enduml 安装 graphviz sudo apt-get install -y graphviz https://graphviz.org/download/ ...

ZooKeeper 节点类型 ZooKeeper 的节点（ZNode）类型是两个维度的组合： 生命周期维度： 持久（Persistent）：客户端断开后节点依然存在，需要显式删除 临时（Ephemeral）：与创建它的客户端 Session 绑定，Session 结束节点自动删除 命名维度： 普通：你指定什么路径就创建什么路径，路径已存在则报错 顺序（Sequential）：路径作为前缀，ZooKeeper 自动追加 10 位单调递增序号 两两组合，实际有四种节点类型： 类型 说明 持久节点 最普通的节点，手动删除才消失 持久顺序节点 名称自动追加递增序号，永久存在 临时节点 Session 结束自动删除 临时顺序节点 Session 结束自动删除 + 名称追加序号 各场景适用类型： 场景 用哪种 分布式锁（抢占式） 普通临时节点，谁先创建谁得锁 分布式锁（公平排队） 顺序临时节点，序号最小的得锁 Leader 选举 顺序临时节点，序号最小的是 leader 配置中心、服务注册 普通持久节点 临时节点原理 ZooKeeper 客户端连接服务端后会建立一个 Session，并维持心跳（默认每隔 tickTime 发一次）。服务端为每个 Session 设置超时时间（sessionTimeout），超时内未收到心跳则判定 Session 过期，自动删除该 Session 创建的所有临时节点，其他 watch 了这些节点的客户端会收到删除通知。 状态 临时节点是否消失 网络抖动（短暂断开） 不消失，等待重连，Session 未过期 断开超过 sessionTimeout 消失，Session 过期 客户端主动 close() 立即消失 临时节点不能有子节点，因为它的生命周期是不确定的。 ...

技术能力 扎实的基础：数据结构、算法、操作系统、网络、数据库原理 系统设计能力：能权衡取舍，设计可扩展、可维护的系统 调试与排障：能快速定位问题，善用工具（profiler、日志、监控） 阅读代码：能快速理解陌生代码库，而不只是写代码 持续学习：技术演进快，能主动跟进新技术而不盲目追新 工程素养 写可读代码：代码是写给人看的，命名清晰，逻辑直白 测试意识：主动写测试，而不是依赖 QA 兜底 版本控制规范：清晰的 commit message，合理的分支策略 文档意识：在合适的地方写合适的文档（不是每行都注释） 安全意识：代码层面的 OWASP 意识，不把安全留给"以后再说" 协作能力 沟通清晰：能向非技术人员解释技术问题，能在 code review 中表达具体意见 估时准确：能分解任务，给出相对可靠的工时估算 主动暴露问题：遇到 blocker 早说，而不是默默卡住 思维方式 系统思维：看到局部问题时，能思考对整体的影响 务实：不追求完美设计，在"够好"和"完美"之间找到正确点 ownership：对自己负责的东西有主人翁意识，上线后持续关注 简单优先：倾向于简单方案，而不是过度设计；代码越少越好 软技能 抗压与专注：在复杂问题面前不慌，能保持有效的思考 接受反馈：对 code review 意见开放，不把技术讨论变成自我防卫 好奇心 好奇心是一个底层驱动力，而不只是加分项。软件工程本质上是一个持续解决未知问题的职业。好奇心驱动你： 追问"为什么这样设计"，而不只是"怎么用" 遇到 bug 时愿意深挖根因，而不是绕过去 主动探索新技术，而不是等公司安排培训 对系统的运行机制真正感兴趣，而不只是完成任务 没有好奇心的工程师可以把当前的工作做得"够用"，但很难做到深入——他们写的代码能跑，但不理解为什么。 好奇心本身还不够，它需要配上自律和落地能力。有些人什么都好奇，但浅尝辄止，或者永远在学新东西却从不完成一件事——这是好奇心失控的版本。 更完整的表述是：有边界的好奇心——对核心领域深挖，对周边领域保持开放，但不被新鲜感分散焦点。 如果只能选一条：能把复杂问题分解成可执行的小步骤，并持续交付——这是区分普通工程师和优秀工程师最核心的能力。 AI 时代的变化 AI 时代这些素质的重心发生了偏移，而不是全部推翻。 更重要了的 阅读和判断代码：AI 生成代码的速度远超人类，“写"的比重下降，“读、评估、审查"的比重上升 问题分解：指挥 AI 的前提是你能把问题拆清楚——分解不清，AI 给你的结果也是乱的 基础原理：AI 输出的代码"看起来对"但可能暗藏问题，没有基础你抓不住错误 判断力与品味：AI 永远给你一个"合理的答案”，但合理不等于正确，你需要能辨别好坏 系统思维：AI 处理局部，人负责全局，整体架构、权衡取舍仍然是人的责任 变得不那么关键的 记忆语法、API 细节——AI 比你记得更准 写样板代码的速度——AI 秒完成 从零实现标准算法——直接生成即可 新增的 AI 协作能力：知道什么时候用 AI、怎么引导、怎么验证输出 怀疑 AI 输出的习惯：不盲从，始终验证正确性、安全性、性能 更强的 ownership：AI 会产出大量代码，但责任仍然在人，“AI 写的"不是借口 好奇心在 AI 时代更重要，因为工具变化极快，好奇心驱动你持续理解 AI 的能力边界，而不是停留在一年前的用法上。 ...

简介 LevelDB 是由 Google 工程师 Jeff Dean 和 Sanjay Ghemawat 开发的开源 KV 存储引擎，两人同时也是 Bigtable 和 MapReduce 的主要设计者。LevelDB 可以理解为单机版的 Bigtable Tablet Server，能够处理十亿级别规模的 Key-Value 数据持久性存储。 主要特性： 数据按 Key 有序存储，支持自定义比较函数 提供 Put / Get / Delete 以及原子批量操作接口 支持 Snapshot 快照读，读操作不受并发写影响 支持 Snappy 数据压缩 写性能极高：随机写约 40 万条/秒，随机读约 6～10 万条/秒（4核机器） 写速度远大于读速度；顺序读写远快于随机读写 LevelDB 是单进程嵌入式库，不提供网络服务，适合作为其他系统的本地存储引擎。Chrome 浏览器用它存储 IndexedDB 数据，比特币/以太坊节点用它存储区块链状态。 LSM-Tree LevelDB 的核心数据结构是 LSM-Tree（Log-Structured Merge-Tree），一种针对写入密集型场景优化的存储结构。 核心思想： 将随机写转化为顺序写，以牺牲部分读性能换取极高的写入吞吐量。 写入流程 写入请求 ↓ WAL（预写日志，顺序写磁盘） ↓ MemTable（内存，有序跳表 SkipList） ↓ 满了之后 Immutable MemTable（只读，等待 flush） ↓ flush（minor compaction） L0（SSTable 文件，磁盘） ↓ compaction（major compaction） L1 → L2 → ... Ln 三大放大问题 问题 说明 写放大 数据会被反复 compaction，实际写磁盘量远大于原始数据量，通常 10x～30x 读放大 读时需要依次查 MemTable → Immutable MemTable → L0 → L1 → … 空间放大 同一 key 可能存在多个版本，直到 compaction 才合并清理 为什么写快 所有写入都是顺序 I/O（追加 WAL、批量 flush） 没有 B-Tree 那样的随机写和页分裂开销 一次写入只涉及一次磁盘顺序追加写 + 一次内存 SkipList 插入 使用 LSM-Tree 的系统 LevelDB / RocksDB — 经典实现（RocksDB 是 LevelDB 的增强版） Cassandra、HBase — 分布式存储 ClickHouse MergeTree — 列式存储引擎 静态结构 LevelDB 的数据存储在内存和磁盘两部分，主要由六个组件构成： ...

Command Dispatcher（命令分发器）和 Command Bus（命令总线）是架构模式，属于应用层架构设计的范畴，不在 GoF 23 种设计模式之列。 注意：“Command Dispatcher” 是开发者社区的口语化称呼，没有权威模式书籍正式定义。对应的正式模式名是 EIP（企业集成模式）中的 Content-Based Router（见下文）。 两者不是同一个模式，Command Bus 是在 Content-Based Router 基础上增加了中间件管道的演化版本，核心差异在于中间件管道。 Command Dispatcher Command Bus 核心机制 ID → Handler 直接路由 ID → 中间件链 → Handler 中间件支持 无 有（日志、验证、事务等） 复杂度 简单 较复杂 典型场景 IoT 协议解析、游戏指令 CQRS、DDD 应用层 Command Dispatcher 核心结构： 收到消息 → 解析 ID → registry.get(id) → handler.Handle(data) 服务初始化时将每种指令的处理类注册到一个 Map。运行时收到消息后，解析出消息类型 ID，从注册表查找对应处理器并直接调用。 // Handler 接口，每种指令实现一个 type Handler interface { Handle(data []byte) error } // Dispatcher 维护 id -> handler 的注册表 type Dispatcher struct { handlers map[uint8]Handler } func NewDispatcher() *Dispatcher { return &Dispatcher{handlers: make(map[uint8]Handler)} } func (d *Dispatcher) Register(id uint8, h Handler) { d.handlers[id] = h } func (d *Dispatcher) Dispatch(id uint8, data []byte) error { h, ok := d.handlers[id] if !ok { return fmt.Errorf("unknown command id: 0x%02X", id) } return h.Handle(data) } // --- 具体指令处理类 --- type LoginHandler struct{} func (h *LoginHandler) Handle(data []byte) error { fmt.Printf("处理登录指令: %x\n", data) return nil } type LocationReportHandler struct{} func (h *LocationReportHandler) Handle(data []byte) error { fmt.Printf("处理位置上报: %x\n", data) return nil } // --- 初始化注册 --- func main() { d := NewDispatcher() d.Register(0x01, &LoginHandler{}) d.Register(0x02, &LocationReportHandler{}) // 收到一条原始消息，解析出 id=0x02 d.Dispatch(0x02, []byte{0x01, 0x02, 0x03}) } Command Bus 在 Dispatcher 的基础上增加了中间件管道，每条命令在到达 Handler 之前会依次经过所有中间件。 ...

AI Agent AI Agent（人工智能代理）是一个能够感知环境、自主决策并采取行动以完成目标的软件系统。 与普通程序不同，AI Agent 的核心特征是自主性：它不只是被动地响应单次输入，而是能够： 制定多步骤计划 调用外部工具（搜索、代码执行、API 调用等） 根据执行结果动态调整策略 持续循环直到目标完成 AI Agent 的定义 从学术角度，Agent 的经典定义来自 Russell & Norvig（《人工智能：一种现代方法》）： Agent 是任何能够通过传感器感知环境、并通过执行器对环境采取行动的事物。 在 LLM 时代，AI Agent 的定义更具体： AI Agent 是以大语言模型为核心推理引擎，能够自主规划任务、调用工具、与外部系统交互，并通过反馈循环完成复杂目标的自治系统。 Agent 的四个核心要素 要素 说明 感知（Perception） 接收输入：多模态用户指令、工具返回结果、系统状态、历史记忆 规划（Planning） 将目标分解为可执行的子任务序列 行动（Action） 调用工具、执行代码、调用 API、操作文件等 记忆（Memory） 短期记忆（上下文窗口）+ 长期记忆（向量数据库等） 感知的来源 感知不只是用户输入那一句话，Agent 每次推理前收到的完整上下文都属于"感知"： 来源 说明 多模态输入 用户的文本指令（最常见）、图片、音频、视频等 工具返回结果 搜索结果、API 响应、代码执行输出、数据库查询结果 系统状态 文件内容、环境变量、当前任务进度 历史记忆 短期记忆（上下文窗口中的对话历史）+ 长期记忆（从向量数据库检索） 这四类来源最终都会被拼装进 LLM 的上下文窗口，LLM 基于这个完整上下文做出下一步决策。因此，感知本质上是构建 LLM 输入上下文的过程。 上下文窗口：感知的硬性约束 能放入上下文的信息量取决于模型的上下文窗口大小（以 token 计）： 模型 上下文窗口 GPT-4o 128K tokens Claude 3.5 Sonnet 200K tokens Gemini 1.5 Pro 1M tokens 超出窗口的内容会被截断，因此 Agent 需要主动管理上下文。常见策略如下（各框架实现不一，没有统一标准）： ...

inode An inode stores all the information about a regular file, directory, or other file system object, except its data and name. 每个文件都对应一个 inode, inode 存储了除文件名和文件内容之外的所有信息。 inode (发音: eye-node) 译成中文就是索引节点, 它用来存放文件和目录的基本信息, 包含时间、档名、使用者，群组，权限， 一个文件占用一个inode,同时记录此文件的数据所在的 block 号码； http://www.ruanyifeng.com/blog/2011/12/inode.html inode是什么？ inode是一个重要概念, 是理解 Unix/Linux 文件系统和硬盘储存的基础。 我觉得,理解 inode, 不仅有助于提高系统操作水平, 还有助于体会 Unix 设计哲学, 即如何把底层的复杂性抽象成一个简单概念, 从而大大简化用户接口。 下面就是我的inode学习笔记,尽量保持简单。 理解inode 作者: 阮一峰 inode是什么？ Inode 用于存储文件或目录的信息. 理解inode, 要从文件储存说起。 扇区 (Sector) 文件储存在硬盘上, 硬盘的最小存储单位叫做"扇区" (Sector) 。每个扇区储存 512 字节。（现在新的硬盘每个扇区有4K） 注意：硬盘的最小存储单位就是扇区了，而且硬盘本身并没有 block 的概念。 文件系统不是一个扇区一个扇区的来读数据，太慢了，所以有了 block（块）的概念，它是一个块一个块的读取的，block 才是文件存取的最小单位。 ...

archlinux packages 本文逐步记录我的 Arch Linux 系统中安装的软件包，目标是了解每个包在当前系统中的用途，以及它是否是必要的依赖（能否安全删除）。 aalib: ASCII art graphic library aardvark-dns: Authoritative DNS server for A/AAAA container records abseil-cpp: Collection of C++ library code designed to augment the C++ standard library adwaita-fonts: GNOME Adwaita 字体，被 wechat 等应用依赖 ansible: IT automation tool ansible-core: Ansible core engine aom: Alliance for Open Media video codec appstream: Provides a standard for creating app stores across distributions archlinux-appstream-data: Arch Linux application database for AppStream-based software centers at-spi2-core: Protocol definitions and daemon for D-Bus at-spi audit: Userspace components of the audit framework avahi: Service Discovery for Linux using mDNS/DNS-SD (compatible with Bonjour) baloo-widgets: KDE Baloo 搜索框架集成小部件 bluez-libs: Deprecated libraries for the bluetooth protocol stack boost-libs: Boost C++ 通用库运行时动态库，详见 boost-libs botan: Crypto library written in C++ bubblewrap: 非特权沙箱工具，详见 bubblewrap btrfs-progs: Userspace utilities to manage btrfs filesystems c-ares: 异步 DNS 解析 C 库，被 curl、Node.js 等广泛使用 ca-certificates-mozilla: Mozilla’s set of trusted CA certificates cfitsio: C/Fortran library for reading and writing FITS data format files chrony: Lightweight NTP client and server conmon: OCI container runtime monitor cryptsetup: Userspace setup tool for transparent encryption of block devices using dm-crypt dav1d: AV1 cross-platform decoder focused on speed and correctness expat: C 语言实现的流式 XML 解析库（libexpat），详见 expat fftw: A library for computing the discrete Fourier transform (DFT) fzf: General-purpose command-line fuzzy finder gcr: A library for bits of crypto UI and parsing glslang: OpenGL Shading Language 编译器和验证器，详见 glslang gnutls: A library which provides a secure layer over a reliable transport layer gtk-update-icon-cache: GTK icon cache updater hwdata: Hardware identification databases iproute2: IP routing utilities libavif: Library for encoding and decoding .avif files libplist: Library to handle Apple Property List files libx11: X11 client-side library expat C 语言实现的流式 XML 解析库（libexpat），采用 SAX（事件驱动）解析模型，适合处理大型 XML 文档。当前系统被以下包依赖：antigravity（Google 的 AI 辅助 IDE 工具）、avahi（mDNS/DNS-SD 零配置网络服务）、cmake（跨平台构建系统）、dbus（进程间通信总线）、dbus-broker（D-Bus 的替代实现）、exiv2（图片元数据读写库）、fontconfig（字体配置库）、gdb（GNU 调试器）、git（版本控制工具）、mesa（OpenGL/Vulkan 图形驱动实现）、neon（HTTP/WebDAV 客户端库）、polkit（权限授权框架）、python（Python 解释器）、qt6-webengine（Qt6 网页渲染引擎）、vtk（3D 可视化工具库）、wayland（显示服务协议库）、webkit2gtk-4.1（WebKit 网页渲染引擎）、wechat-bin（微信桌面客户端）。 ...

AI Agent 开发的本质 开发 AI Agent 的核心是将已验证的知识和流程固化成可执行的规则和指令。 具体来说： 知识固化 - 把专家经验、最佳实践、业务规则编码成 Agent 可以遵循的指令 流程自动化 - 将重复性的决策流程转化为确定性的执行步骤 质量保障 - 通过固化的规则确保每次执行的一致性，避免人为疏忽 迭代优化 - 每次发现新问题或更好的做法，就更新这些"固化的知识"，Agent 的能力随之提升 本质上是把隐性知识显性化，把经验驱动变成规则驱动。 这也意味着 Agent 的质量上限取决于你固化进去的知识质量。垃圾进，垃圾出；好的经验进，稳定的高质量输出。 为什么需要固化知识 LLM 的知识覆盖面极广，解决同一个问题可能有多条路径，但其中只有少部分是最佳实践。具体输出什么内容，很大程度上取决于提示词的质量。 把已验证的解决方案固化到 Agent 里，能让 Agent 在特定领域有更稳定、更优质的表现——相当于给 LLM 划定了一条"黄金路径"，避免它在众多可能性中随机游走。 常用技术栈 编程语言 Python（主流，生态丰富） JavaScript/TypeScript（Web/Node.js Agent） Go、Java（高性能/企业级） 大语言模型与 API OpenAI GPT-4/3.5、Claude、Llama Hugging Face Transformers LangChain、LlamaIndex（Agent 框架） Web 框架与服务 FastAPI、Flask（Python） Express.js（Node.js） Django 数据存储 Redis、MongoDB、PostgreSQL、SQLite 向量数据库：Milvus、Pinecone、Weaviate 消息队列与异步任务 Celery、RabbitMQ、Kafka 容器与部署 Docker、Kubernetes 云服务：AWS、Azure、GCP 前端交互 React、Vue.js WebSocket、RESTful API 其他 Prompt 工程、工具插件系统 OAuth2、JWT（安全认证） 日志与监控：Prometheus、Grafana Python 调用模型方式 AI Agent 用 Python 开发时，可以调用本地模型或云端模型： ...

MCP 是什么 MCP（Model Context Protocol，模型上下文协议）是一个开源标准协议，用于将 AI 应用与外部系统连接起来。 可以把 MCP 理解为 AI 应用的 USB-C 接口。就像 USB-C 为电子设备提供了标准化的连接方式，MCP 为 AI 应用与外部系统的连接提供了统一标准。 有了 MCP，Claude、ChatGPT 等 AI 应用可以连接到： 数据源：本地文件、数据库 工具：搜索引擎、计算器、代码执行环境 工作流：自定义 prompt 模板、业务系统 MCP 解决了什么问题 问题背景 在 MCP 出现之前，每个 AI 应用如果想连接外部工具或数据源，都需要为每种组合单独开发集成代码。这导致： 重复开发：A 工具想接 GitHub，B 工具也想接 GitHub，各自写一套 维护成本高：N 个 AI 应用 × M 个外部工具 = N×M 个集成要维护 互不兼容：为 Claude 写的插件不能直接用在 ChatGPT 上 MCP 的解决方案 MCP 引入了统一的 Client-Server 架构： MCP Server：外部工具/数据源的提供方，按照 MCP 协议暴露能力 MCP Client：AI 应用（如 Claude、VS Code Copilot），按照协议调用 Server 这样只需要： ...

微服务 微服务是一种分布式系统解决方案。 微服务 (Microservices) 就是一些协同工作小而自治的服务。 2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现 。 微服务与SOA 「面向服务的体系结构」 SOA (Service-Oriented Architecture) 听起来和微服务很像,但 SOA 早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如: J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间,最终 SOA 看起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。 此外,实施SOA时会遇到很多问题,比如通信协议 (例如SOAP)的选择、第三方中间件如何选择、服务粒度如何确定等,目前也存在一些关于如何划分系统的指导性原则,但其中有很多都是错误的。SOA并没有告诉你如何划分单体应用成微服务,所以在实施SOA时会遇到很多问题。 这些问题再微服务框架中得到很好的解决,你可以认为微服务架构是SOA的一种特定方法。 分布式系统 什么是分布式系统 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。 首先需要明确的是,只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候,且硬件的提升 (加内存、加磁盘、使用更好的CPU) 高昂到得不偿失的时候,应用程序也不能进一步优化的时候,我们才需要考虑分布式系统。因为,分布式系统要解决的问题本身就是和单机系统一样的,而由于分布式系统多节点、通过网络通信的拓扑结构,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的机制、协议,带来更多的问题。 “什么是分布式系统？这取决于看系统的角度。对于坐在键盘前使用IBM个人电脑的人来说,电脑不是一个分布式的系统。但对于在电脑主板上趴着的虫子来说,这台电脑就是一个分布式系统。” —— Leslie Lamport 复杂性 流量管理 (Traffic management) : 超时、重试、负载均衡； 安全性 (Security) : 终端用户的认证和授权； 可观察性 (Observability) : 跟踪、监控和日志。 私有数据的所有权 当多个服务直接读写数据库中同一张表时,对这些表做任何改动都需要协调这些相关服务的部署。这一点违背了服务相互独立这一原则。共享的数据存储很容易不经意间造成耦合。每个服务需要有自己的私有数据。 私有数据还能提供另一个优势: 根据服务的具体用例选择最适合的数据库技术。 每个服务都要有自己的数据服务器吗？ 不一定。每个服务需要自己的数据库,但这些数据库可共置在一台共享的数据服务器上。重点在于不应让服务知道其他服务底层数据库的存在。这样即可用一台共享数据服务器先开始开发,以后只要更改配置即可将不同服务的数据库隔离起来。 然而共享的数据服务器也可能造成一些问题。首先会形成单点故障,进而导致一大批服务同时故障,这一点绝不能掉以轻心。其次很可能因为一个服务占用太多资源而无意中对其他服务造成影响。 确定服务的边界 这个问题很复杂。每个服务应该是一种能提供某些业务能力的自治单位。 服务应当弱耦合在一起,对其他服务的依赖应尽可能低。一个服务与其他服务的任何通信都应通过公开暴露的接口 (API、事件等) 实现,这些接口需要妥善设计以隐藏内部细节。 服务应具备高内聚力。密切相关的多个功能应尽量包含在同一个服务中,这样可将服务之间的干扰降至最低。 服务应包含单一的界限上下文。界限上下文 (Bounded context) 可将某一领域的内部细节,包括该领域特定的模块封装在一起。 ...

主流持久层框架 Spring Data JPA + Hibernate Spring Boot 默认推荐，依赖 spring-boot-starter-data-jpa ORM 框架，用注解映射对象和表 自动生成 SQL，支持 JPQL / Criteria API 适合领域模型复杂的场景 MyBatis / MyBatis-Plus 半自动 ORM，SQL 写在 XML 或注解中 对 SQL 控制力强，适合复杂查询 MyBatis-Plus 提供代码生成、分页等增强功能 JOOQ 类型安全的 SQL DSL，SQL 风格写法 编译期检查 SQL，适合喜欢写 SQL 的团队 商业数据库需付费版 Spring Data JDBC 比 JPA 更轻量，无懒加载、缓存等复杂特性 SQL 更透明，适合简单 CRUD R2DBC（响应式） 非阻塞响应式驱动，配合 WebFlux 使用 依赖 spring-boot-starter-data-r2dbc 选型建议 场景 推荐 快速开发，标准 CRUD Spring Data JPA 复杂 SQL，精细控制 MyBatis-Plus 强类型 SQL，重查询业务 JOOQ 响应式架构 R2DBC 连接池 Spring Boot 默认使用 HikariCP 作为连接池。 ...

概述 JDK 17 是 Java 的长期支持版本（LTS），于 2021 年 9 月发布。相比 JDK 16，JDK 17 引入了多项新特性和改进，同时也包含了一些孵化特性的正式毕业版本。 正式特性（JEP） JEP 306: 恢复始终严格的浮点语义 将浮点运算恢复为始终严格模式（strict），删除了 strictfp 关键字的限制效果。在历史上，Java 曾因不同硬件平台的差异引入了扩展精度模式，随着现代硬件的普及，该差异不再存在，因此恢复了一致的浮点行为。 JEP 356: 增强型伪随机数生成器 提供新的接口和实现用于伪随机数生成器（PRNG），新增了 RandomGenerator 接口和多个算法实现，如 Xoshiro256PlusPlus、L64X128MixRandom 等。 RandomGenerator generator = RandomGeneratorFactory.of("L64X128MixRandom").create(); int randomInt = generator.nextInt(100); JEP 382: 新的 macOS 渲染管道 使用 Apple Metal API 实现 Java 2D 渲染管道，替代已废弃的 OpenGL API，提升在 macOS 上的图形渲染性能。 JEP 391: macOS/AArch64 移植 将 JDK 移植到 macOS/AArch64（Apple Silicon）平台，支持原生运行于 M1 及后续芯片的 Mac 电脑。 JEP 398: 废弃 Applet API 正式废弃 Applet API，标记为 @Deprecated(forRemoval = true)。浏览器早已不再支持 Java 插件，该 API 已无实际用途。 ...