<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on Kory&#39;s Blog</title>
    <link>https://blog.555586.xyz/posts/</link>
    <description>Recent content in Posts on Kory&#39;s Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-cn</language>
    <lastBuildDate>Wed, 30 Sep 2026 01:31:03 +0000</lastBuildDate><atom:link href="https://blog.555586.xyz/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>EdgeEver 笔记 -&gt; GitHub -&gt; Vercel 博客自动化流水线与构建排坑全指南</title>
      <link>https://blog.555586.xyz/posts/edgeever-github-vercel-blog-pipeline-troubleshooting/</link>
      <pubDate>Wed, 30 Sep 2026 01:31:03 +0000</pubDate>
      
      <guid>https://blog.555586.xyz/posts/edgeever-github-vercel-blog-pipeline-troubleshooting/</guid>
      <description>本文档完整记录从 EdgeEver 笔记打标、经过 Blog MCP 推送 GitHub、再到 Vercel 自动构建 Hugo 博客并绑定 Cloudflare 自定义域名的全流程。重点复盘部署过程中因为 Framework 预设、环境变量版本号、Extended 依赖及快照机制导致的多次构建失败根因与彻底解决方案。
一、 整体技术架构与流转链路 [EdgeEver 笔记] (打标 blog / 博客 + 毫秒级锁定原始时间戳) │ ▼ (Blog MCP / Cloudflare Worker: publish_post) [GitHub 仓库] (kyaring/myblog -&amp;gt; content/posts/*.md) │ ▼ (Webhook 自动触发推送事件) [Vercel CI/CD] (注入 HUGO_VERSION 环境变量 -&amp;gt; Hugo Extended 编译静态站点 public/) │ ▼ (CNAME 记录 DNS only) [Cloudflare DNS] (blog.555586.xyz -&amp;gt; Vercel CDN 自动化 SSL) 源头管理：在 EdgeEver 中编写笔记，添加 blog 标签； 发布调度：Blog MCP 将笔记格式化为带 FrontMatter（title, date, tags, slug）的标准 Markdown，调用 GitHub API 提交并推送到仓库； 自动化部署：Vercel 监听 GitHub main 分支变动，自动拉取并根据环境变量指定版本运行 Hugo Extended 生成 HTML； 终端访问：Cloudflare DNS 解析至 Vercel，提供全球加速与自动化 HTTPS。 二、 核心部署踩坑复盘（为什么错了好几次？哪里出了错？） 在本次实际部署中，由于对 Vercel 构建镜像的预装机制、版本回退策略以及主题对 SCSS 的硬性依赖认识不足，导致连续构建失败、反复重试。以下为具体技术细节还原：</description>
    </item>
    
    <item>
      <title>🇩🇪 德国税号 (Tax ID) 校验与格式指南</title>
      <link>https://blog.555586.xyz/posts/germany-tax-id-validation-guide/</link>
      <pubDate>Tue, 29 Sep 2026 23:40:01 +0000</pubDate>
      
      <guid>https://blog.555586.xyz/posts/germany-tax-id-validation-guide/</guid>
      <description>🇩🇪 德国税号 (Tax ID) 校验与格式指南 本文档总结了德国三类主要税号的格式规范与校验逻辑，供校验站点开发与测试使用。
1. 个人终身税号 (Steuer-Identifikationsnummer / IdNr) 用途：个人所得税、银行、社保。 格式：11 位数字。 逻辑规则： 首位不能为 0。 前 10 位中，必须且仅有一个数字出现 2 次或 3 次，其余数字不重复。 校验位：第 11 位是基于前 10 位的校验码（算法：ISO 7064 MOD 11, 10 变体）。 测试用例：52113674892、65928134705。 2. 营业税号 (Steuernummer / St.-Nr.) 用途：自由职业或公司在所属税务局报税。 格式：10-11 位（常见：FF/BBB/UUUUU）。 特点：格式随联邦州改变。搬家后会换号。 示例：11/123/45678 (柏林)。 3. 欧盟增值税号 (Umsatzsteuer-Identifikationsnummer / USt-IdNr.) 用途：欧盟跨境贸易 (B2B)。 格式：DE + 9 位数字。 测试用例： 大众汽车: DE115235681 西门子: DE129274202 验证工具：欧盟官方 VIES 接口。 开发者建议：
校验时优先实现 MOD 11 算法。 边界测试需包含：首位为0、前10位无重复、第11位校验失败等场景。 </description>
    </item>
    
  </channel>
</rss>
