26 篇
1 个三级分类
三级分类
技术笔记整理
技术体系化整理、工程实践与开发笔记。
专题分组
二级专题与三级分类
39 篇
2 个三级分类
19 篇
3 个三级分类
42 篇
2 个三级分类
12 篇
2 个三级分类
26 篇
3 个三级分类
1 篇
1 个三级分类
三级分类
当前页继续展示这个根分类下的全部文章；上面的二级专题和三级分类用于快速定位更细的主题入口。
开发工具2 分钟
cursor-vscode配置cpp环境
这份记录聚焦在 macOS 环境下为 Cursor 或 VS Code 搭建一个最小可用的 C++ 编写与运行环境，目标不是完整工程化配置，而是先让本地代码能跑起来并具备基础编辑辅助。操作从命令行安装编译器开始，使用 brew install gcc，并通过 gcc --version、which gcc 检查当前 gcc 命令的实际版本与路径；示例输出显示其指向 Apple clang，路径位于 /usr/bin/gcc，这一点有助于理解 macOS 上 gcc 命令可能并非 GNU GCC。编辑器侧安装 Code Runner 插件后，可以直接点击右上角运行按钮，用包含 cin 输入和 cout 输出的 Hello World 程序验证标准输入输出流程是否正常。随后补充安装 ms-vscode.cpptools，用于提供 C++ 代码跳转等语言辅助能力，使编辑体验不只停留在运行单文件代码。整体适合刚开始在 macOS 上使用 Cursor、VS Code 写 C++ 的读者，用来快速确认编译器、运行插件和跳转插件三件事是否到位；需要更复杂的多文件工程、调试配置或 CMake 集成时，还需要在此基础上继续扩展。
6 分钟
什么是Rosetta
这篇笔记围绕 Apple Silicon 上的 Rosetta 2 展开，说明它本质上是 Apple 提供的 Intel x86_64 到 ARM 的动态二进制翻译机制，用来让 M1/M2/M3 设备运行只提供 Intel 架构的应用、解释器或动态库。正文把“Rosetta 终端”和“x86 程序运行”拆开说明：右键 Terminal 或 iTerm 勾选“使用 Rosetta 打开”会让该终端下的进程偏向 x86_64 模式，但启动 x86 可执行程序时 Rosetta 也可以被系统自动触发。文章重点澄清了几个常见误判，uname -m 只能反映当前终端架构，而 platform.machine() 更接近当前 Python 解释器进程的架构；因此 ARM 终端中运行 x86 Conda/Python 并不矛盾。对于 rocketmq-client-cpp、librocketmq.dylib 等依赖 x86 动态库的场景，关键不是终端显示什么架构，而是解释器、动态库和相关依赖是否同为 x86_64，否则就会出现架构不一致问题。笔记还提醒 Homebrew 的安装来源会受运行模式影响，在 Rosetta 终端中执行 brew install 可能安装 x86_64 构建的包，后续与 arm64 环境混用时需要特别留意。整体适合在 Apple Silicon 上维护 Python、Conda、brew 依赖或排查旧版二进制兼容问题的开发者，用来判断什么时候必须开启 Rosetta 终端、什么时候只需保证进程与动态库架构一致。
30 分钟
邮件协议、签名与推送
围绕邮件客户端“整合邮箱”时到底发生了什么，内容先把 SMTP、POP3、IMAP、Webmail、MTA/MDA 的职责拆开：SMTP 负责发信和服务器中继，POP3/IMAP 负责取信与同步，浏览器里的 HTTPS 只是访问 Gmail、Outlook 等 Web UI 的界面层协议。笔记进一步说明 Spark、Apple Mail、Gmail App 等并不是被邮箱服务器直接“推送”邮件，而是依赖定时轮询、IMAP IDLE 长连接，或在移动端通过 APNs、FCM 等通知系统实现近实时提醒。发信可信度部分强调，邮件由谁配置的 SMTP 发出，DKIM、SPF、DMARC 和发信 IP 信誉就主要归谁控制；使用 Gmail SMTP 时，签名和背书来自 Gmail，自建或小服务商 SMTP 则更依赖 SPF、DKIM、PTR、Return-Path 等配置质量。文章还区分了客户端壳子与真正发信服务器的关系，说明 iCloud、Spark、Apple Mail、QQ/网易等整合外部邮箱时，本质都是调用 IMAP/SMTP，只是授权方式、专用密码和风控流程不同。隐私部分重点比较 Apple Mail 本地直连邮箱服务器、只借助 APNs 做状态通知的模式，与 Spark、Edison、Outlook 移动端等可能通过自家云端代收、缓存、分析邮件并转发推送的模式。适合想判断邮件送达率、签名归属、移动端推送延迟以及第三方邮件 App 隐私风险的开发者、运维人员和重度邮箱用户阅读。
1 分钟
关于“计算机知识”类别
“计算机知识”类别适合用于归档具有稳定主题边界的计算机相关内容，重点在于帮助读者按知识领域筛选文章，而不是简单提供一个宽泛标签。该类别的使用需要先说明设立理由：它服务于哪些问题、知识点或学习场景，以及这些内容为什么不宜散落在其他分类中。归类时应明确它与现有类别的差异，例如是否覆盖基础概念、系统原理、网络、硬件、软件使用或通用技术认知等范围，并避免与更具体的开发、运维、工具类栏目重复。类别说明还应给出纳入准则，帮助后续文章判断是否符合共同特征。对于维护者来说，这一类别的价值在于建立可持续的内容组织规则，同时也要定期评估其必要性：若内容过少、边界模糊或与其他分类高度重叠，就应考虑合并为子类别或调整定位。
开发工具14 分钟
cloudfare+gmail 配置 smtp 邮箱
这篇笔记记录了一套个人域名邮箱的轻量方案：把域名 DNS 托管到 Cloudflare，用 Cloudflare Email Routing 负责收信转发，再借助 Gmail 的 SMTP 功能以自定义域名地址发信，从而避免自建邮件服务器。配置前需要先在 Namecheap 等注册商处把 NS 切换为 Cloudflare，因为 Cloudflare 只有接管权威 DNS 后，才能统一管理 MX、TXT、CNAME 等记录，并提供后续的 CDN、防护和证书能力。收信部分的关键是启用 Cloudflare 邮件路由，让系统自动写入 route1/route2/route3.mx.cloudflare.net 等 MX 记录，并在后台把 name@域名 转发到 Gmail、QQ 等真实邮箱。文章特别强调邮件 DNS 记录不能混用：iCloud+、Google Workspace 或 Cloudflare 的 MX 入口只能保留一套，SPF、DKIM、DMARC 也不能随意叠加，否则可能导致验证失败、进入垃圾箱或退信。发信部分则在 Google 账户中生成应用专用密码，再到 Gmail 的“账号和导入”里添加其他发件地址，SMTP 服务器填写 smtp.gmail.com、端口 587、用户名为 Gmail 地址，并通过确认邮件完成验证。它还解释了一个容易混淆的点：MX 只决定收信入口，所以 dig MX 仍会看到 Cloudflare；真正发信走的是 Gmail SMTP，Cloudflare 不参与发信链路。适合已有个人域名、希望拥有多个自定义邮箱别名，并希望用免费或低维护方式完成收发配置的用户参考。
服务器与部署16 分钟
cloudfare配置内网穿透
这篇记录围绕 Cloudflare Tunnel 搭建内网穿透展开，适用于希望把本地 FastAPI、管理后台或前端开发服务通过自有域名暴露到公网、但没有公网 IP 或不想做路由器端口映射的场景。流程从域名接入 Cloudflare 开始：先在原域名服务商关闭 DNSSEC，再把 NS 修改为 Cloudflare 提供的 Name Servers，并可用 dnschecker 检查 NS 是否已切换成功，因为 Cloudflare 的域名验证主要依赖 NS 接管而不是添加 TXT 记录。正文随后记录 cloudflared 的安装验证、tunnel login 授权、创建 tunnel，以及通过 config.yml 的 ingress 把 api、admin、web 等不同 hostname 映射到 localhost 的不同端口。一个 tunnel 可以承载多个服务，但每个 hostname 仍需分别创建 DNS 路由，既可在控制台添加 CNAME，也可用 cloudflared tunnel route dns 自动生成指向 cfargotunnel.com 的记录。文章还说明接入 Cloudflare 后 Universal SSL 会自动为域名签发并续期 HTTPS 证书，通常无需手动管理证书。排障部分强调 DNS 和隧道生效可能存在延迟，QUIC 连接失败多与 UDP 7844 被阻断有关，可改用 HTTP/2；若访问出现 502，则常见原因是本地目标服务未启动。最后补充了长期运行方式：cloudflared tunnel run 只是前台进程，生产或长期访问应改用系统服务或 nohup，并在修改 config.yml 后重启 cloudflared 才能让新配置生效。
开发工具14 分钟
picgo配置
这份笔记围绕 PicGo + GitHub 搭建免费图床展开，目标是把 GitHub 公开仓库作为图片存储位置，并由 PicGo 自动完成上传、生成链接和复制到剪贴板。内容从创建 image-hosting 之类的公开仓库开始，记录了初始化 README、生成 classic Personal Access Token、仅勾选 repo 权限、保存 token 等准备步骤，并补充了 macOS 安装 PicGo 时遇到“已损坏”提示可用 xattr 或 spctl 命令处理。配置部分重点说明 GitHub 图床需要填写 token、username/repo 格式的仓库名、main 或 master 分支、可选存储路径，以及 raw URL、GitHub Pages 域名或 jsDelivr CDN 域名等访问方式。上传流程覆盖快捷键、拖拽和手动选择文件，生成的链接可按 Markdown、HTML 或 URL 格式用于博客和 Markdown 文档。后半部分进一步解释 GitHub Pages 的用户站点与项目站点差异：免费账户通常只能有一个 username.github.io 用户站点，但可基于多个公开仓库创建项目站点，Pro 账户则可在私有仓库启用 Pages。文中也提醒仓库和 Pages 站点建议控制在 1GB 内，单文件不超过 100MB，图片公开可访问且 token 不能泄露，适合需要低成本托管博客图片并理解链接形式、访问速度与公开性边界的个人开发者。
1 分钟
关于“开发工具使用”类别
“开发工具使用”类别用于承载与开发工具相关的说明性内容，并为后续文章归档提供一套可判断的分类准则。它关注的重点不是单个工具的零散记录，而是说明为什么需要这个类别、它承担什么用途，以及哪些内容应被归入其中。该类别需要明确自身与既有分类的边界，避免与更偏向编程语言、框架实践、环境配置或问题排查的栏目发生重复。适合纳入的内容通常包括工具使用经验、功能说明、工作流整理、选型依据、常见操作规范，以及围绕开发效率展开的实践记录。正文同时提示应评估该类别是否有独立存在的必要，必要时也可以考虑与相近类别或子类别合并。对维护知识库或技术博客分类体系的读者来说，这类说明的价值在于帮助统一归档标准，减少后续发布文章时的分类歧义。
服务器与部署2 分钟
picgo配置cloudflare-r2
这篇记录聚焦于用 PicGo 搭配 Cloudflare R2 搭建博客图床，并通过 Cloudflare 缓存规则改善图片访问速度。配置部分选择的是 wayjam 维护的 picgo-plugin-s3，而不是泛泛说明 S3 协议本身，核心操作是在 PicGo 插件市场安装对应版本后，按 R2/S3 存储参数完成上传配置。文章特别强调上传路径的命名方式，示例为 blog/img/{year}/{month}/{md5}-{timestamp}.{extName}，利用年份、月份、MD5、时间戳和扩展名组合，让对象路径尽量唯一，避免后续缓存命中与文件更新之间产生混淆。完成上传路径后，还需要设置 PicGo 的输出 URL，使上传后的图片能按自定义 CDN 域名路径被博客引用。后半部分转向 Cloudflare 后台的 Cache TTL 自定义规则，因为文件数量增多时每次加载可能变慢，作者通过匹配访问路径并设置缓存时间，让首次访问之后的图片加载更快。整体适合已经具备 PicGo、Cloudflare 域名和 R2 存储基础的用户参考，重点价值在于串起上传、URL 输出和边缘缓存三段链路，而不是从零解释 R2 或 S3 的所有概念。
服务器与部署6 分钟
minio配置
这份笔记面向 MinIO 对象存储的初始配置与公开读取场景，重点把控制台操作和 S3 客户端接入参数对应起来。创建本地用户时，user_name 可作为 MINIO_ACCESS_KEY，password 可作为 MINIO_SECRET_KEY，MINIO_ENDPOINT_URL 通常填写反向代理后的对象存储地址；如果直接用 IP 访问，则需要带上 9000 端口，区域在无特殊配置时可使用 auto。权限体系部分区分了 Users、Groups、OpenID 和 LDAP：本地用户适合直接分配 IAM policy，组用于批量继承权限，OpenID 适合接入 Keycloak、Auth0 等身份提供商实现 SSO，LDAP/AD 则便于复用企业账号和组映射。桶配置部分解释了 Custom Access Policy、服务器端加密、跨集群复制、对象锁、标签和配额等开关的含义，帮助判断哪些能力只是当前禁用，哪些需要按合规、同步或容量管理需求启用。公开文件读取策略示例只允许 GetBucketLocation 和 GetObject，并将对象资源限定在 public 桶下，同时明确不放行 ListBucket，避免匿名用户枚举桶内对象列表。适合正在把 MinIO 作为 S3 兼容存储接入应用、需要配置访问密钥、桶策略和基础权限边界的开发或运维人员参考。