How to Publish by Hugo

标题:如何使用 Hugo 发布文章:从 Markdown 到线上博客的全流程指南 副标题 / 摘要 这篇文章教你如何使用 Hugo 创建、管理与发布文章,包括 front matter 设置、草稿管理、图片处理、目录结构、预览与上线,让你从零掌握完整写作流程。 目标读者 Hugo 初学者 想用 Hugo 搭建技术博客的人 想学习 Markdown + 静态站点写作流程的开发者 使用 PaperMod、DoIt 等主题的用户 背景 / 动机 很多人在成功搭建 Hugo 博客后会遇到新的困惑: 文章应该放在哪个目录? front matter 要怎么写? 图片要放哪? 为什么本地能看到文章但线上看不到? 草稿 / 发布时间如何控制? 怎样让文章自动出现在首页? 这些都是 Hugo 新手非常常见的痛点。 本教程用实战步骤 + 最佳实践帮助你完全掌握“如何发布文章”的整个流程。 核心概念 1. Hugo Content(内容目录) Hugo 的文章都放在 content/ 目录下,比如: content/ posts/ my-first-post.md 2. Front Matter 文章头部的三段 YAML/TOML/JSON,用来控制文章: --- title: "文章标题" date: 2024-08-26 draft: false tags: ["hugo", "blog"] --- 3. Draft(草稿) 草稿不会被构建,只能在本地用 hugo server -D 查看。 ...

2025年11月14日 · 3 分钟 · map[name:Jeanphilo]

用一段优雅的python代码,把sqlalchemy模型高效转为字典

标题 用一段优雅的 Python 代码,把 SQLAlchemy 模型安全、高效地序列化成字典 副标题 / 摘要 SQLAlchemy 模型转字典(dict)看似简单,却暗藏字段格式、关系递归、循环引用等坑。本文通过一段实战代码,带你实现一个可复用的 _to_dict 序列化工具,并分析其设计取舍与改进方向,适合正在用 SQLAlchemy 写后端接口的你。 目标读者 这篇文章适合以下读者: 使用 SQLAlchemy 做 ORM 的后端开发者 想把 ORM 模型转换为 JSON/dict 的 Python 工程师 对 模型序列化规范化 有需求的中级开发者 使用 Flask/FastAPI/Django + SQLAlchemy 的同学 一、背景 / 动机:为什么要自己写 _to_dict? 在 Web 开发中,我们几乎每天都要做一件事: 把数据库里的 ORM 对象,转成可以 JSON 响应给前端的数据结构(通常是 dict / list)。 乍一看好像只是 obj.__dict__ 或用个 asdict 就完事,但现实中的问题包括: 日期时间字段无法直接 JSON 化: datetime / date 对象不能直接 JSON 序列化,必须格式化成字符串。 关系字段怎么处理? 一对多 / 多对多(uselist=True) 一对一 / 多对一(uselist=False) 避免递归爆炸: 两个模型互相关联,很容易序列化时陷入无限递归。 ...

2025年11月12日 · 4 分钟 · map[name:Jeanphilo]

用Issue把问题写清楚,从0到TEMPLATE

标题(吸引且准确,包含关键词) 用 Issue 模板把需求写清楚:从 0 配置 GitHub Issue Template 的完整指南 副标题 / 摘要 这篇文章手把手教你在 GitHub 仓库中配置「新需求 / Feature」与「Bug」Issue 模板,包括目录结构、YAML 表单、Markdown 模板以及常见坑。适合想让团队需求沟通更规范、减少反复追问的开发者和团队负责人。 目标读者 这篇文章适合: 经常在 GitHub 仓库里开 Issue、提需求的 后端 / 前端 / 全栈工程师 想把团队需求提交流程「标准化」的 项目负责人 / TL / 架构师 对 GitHub 已经有基本使用经验、但还没用过 Issue 模板的 中级开发者 完全新手也能看懂,但会默认你知道:什么是仓库、什么是 Issue、如何提交代码等。 背景 / 动机:为什么要折腾 Issue 模板? 没有 Issue 模板时,日常可能是这样的: “这个需求背景是什么?” “影响哪些模块?” “验收标准怎么算通过?” “优先级到底多高?” 一句话 Issue: “做个导出功能” 直接把所有人整破防。 长期下来会有几个痛点: 沟通成本高:每个需求都要反复追问细节; 信息不对称:请求人脑子里很清楚,但写在 Issue 里的只有一句话; 难以排期:没有明确优先级和验收标准,大家都觉得自己的需求是 P0; 历史难追踪:几个月后再看这个 Issue,完全不知道当时怎么想的。 而 GitHub 提供的 Issue Template,其实就是一套「结构化提问」工具: ...

2025年11月11日 · 4 分钟 · map[name:Jeanphilo]

别让Pydantic占领你的整个项目:聊聊API校验,Domain模型和数据库之间的边界

标题 别让 Pydantic 占领你的整个项目:聊聊 API 校验、Domain 模型和数据库之间的边界 副标题 / 摘要 很多用 FastAPI/Pydantic 的 Python 工程师,会不知不觉让 Pydantic Model 贯穿 API、业务、数据库所有层。本文用一个清晰的分层思路和完整代码示例,帮你搞清楚:Pydantic 适合用在什么地方,Domain / ORM 又应该怎么配合。 目标读者 这篇文章适合: 正在使用 FastAPI / Pydantic / SQLAlchemy / SQLModel 的 Python 后端工程师 刚入行 0–3 年、开始关心“分层、架构、领域模型”的开发者 想从“会写接口”进阶到“懂业务建模、懂分层”的工程师 对 “Pydantic 要不要进 Domain / 要不要用于 DB 模型” 有疑惑的人 一、背景 / 动机:为什么 Pydantic 容易“长满全项目”? 如果你是从 FastAPI 入门后端,很可能经历过这样的路径: 用 Pydantic 定义请求体、响应体:太好用了,自动校验 + 文档 + 类型提示。 觉得既然 Pydantic 这么香,那干脆: 直接拿 Pydantic Model 当“业务对象”传来传去 甚至顺手拿它去做“数据库模型” 渐渐地,你的项目变成: ...

2025年11月9日 · 6 分钟 · map[name:Jeanphilo]

从写路由到写"大脑":Python工程师如何先搞定核心逻辑,再考虑API

标题 从写路由到写“大脑”:Python 工程师如何先搞定核心逻辑,再考虑 API 副标题 / 摘要 刚入行时,我们常常一上来就写路由、设计接口、想 chat_id / message_id 怎么存,却发现真正的“智力活”——核心逻辑——总是拖到后面。这篇文章带你从「先写接口」的思维,升级到「先写大脑,再接外壳」,并串起来六边形架构、Clean Architecture、DDD 等背后的经典理念。 目标读者 适合这些同学阅读: 1–3 年经验 的 Python 后端工程师 / AI 应用开发者 正在用 FastAPI / Django / Flask 等框架写 API 的工程师 想从“CRUD 搬砖工”进化为“懂设计、能抽象”的工程师 对 六边形架构 / Clean Architecture / DDD 有点好奇但没系统看过书的人 一、背景 / 动机:为什么“先写接口”会卡死自己? 很多刚入行的 Python 工程师(包括你我)会有这样的流程: 产品提一个新需求:做一个 AI 聊天功能。 打开编辑器,第一反应就是: 设计 URL:POST /api/chat/send_message 开始写 router:@app.post("/chat/send") 想 request body 参数长什么样:chat_id / message_id / user_id / content 想数据库表结构:chats,messages 写了一堆 API、schema、model、迁移脚本之后,才想起来: “那 AI 回复到底是怎么生成的?” ...

2025年11月8日 · 5 分钟 · map[name:Jeanphilo]

api标准

🧭 标题: 如何编写一份合格的 API 文档:从 Tony Tam 的 Swagger 到现代 OpenAPI 实践 ✍️ 副标题 / 摘要 想让你的 API 被开发者真正用得舒服?这篇文章将带你从理念到实践,全面掌握一份高质量 API 文档的结构、示例与最佳规范,基于 Tony Tam 提出的 Swagger / OpenAPI 标准。 🎯 目标读者 初学者:想了解 API 文档标准结构的人。 中级开发者:希望提升接口文档可维护性与规范性的人。 架构师 / 技术负责人:负责 API 设计规范制定与团队协作的人。 💡 背景 / 动机 许多开发团队的 API 文档存在以下痛点: 信息零散,缺乏统一格式; 更新滞后,开发与文档脱节; 无法直接用于自动生成或测试。 Tony Tam 于 2010 年提出的 Swagger 规范(后更名为 OpenAPI) 正是为了解决这些问题。如今,它已成为 RESTful API 文档的事实标准,被 Google、Amazon、Stripe 等公司广泛采用。 🔍 核心概念 概念 说明 API 文档 描述应用程序接口如何被调用、请求与响应的技术说明书。 Swagger / OpenAPI 一种用于定义、生成、测试 REST API 的标准化规范。 Endpoint(端点) API 中可访问的具体路径(如 /users/{id})。 Schema(数据模型) 定义请求与响应的字段结构。 🧰 实践指南 / 步骤 明确文档结构 ...

2025年11月6日 · 2 分钟 · map[name:Jeanphilo]

从堵塞到异步:为什么上传文件接口不该等文件处理完

🚀 从阻塞到异步:为什么上传接口不该等文件处理完? —— 用异步任务和状态跟踪构建高性能文件处理系统 🧭 副标题 / 摘要 在现代 Web 系统中,文件上传只是起点,真正的挑战在于后续的解析、索引和处理。本文带你理解为什么“上传接口不等待处理完成”是现代架构的核心理念,以及如何通过异步任务 + 状态查询实现稳定、可扩展的后台处理系统。 👥 目标读者 有一定 Web 开发经验的工程师(Python/FastAPI/Node.js 等) 想优化后端性能、提高可扩展性的中级开发者 对架构设计、异步系统感兴趣的工程师或技术负责人 🎯 背景 / 动机 很多初学者写上传接口时会这样做: @app.post("/upload") def upload_file(file: UploadFile): parse_and_store(file) # 阻塞操作 return {"status": "completed"} 表面简单,实则隐藏问题: ⏱ 超时风险高(解析/embedding/OCR可能几分钟) 🧵 阻塞主线程,拖慢整个 API 服务 💥 请求中断即任务丢失 😕 用户只能干等着,无法看到进度 解决方案就是:上传与处理分离。上传只负责“投递任务”,处理由后台 worker 异步执行,状态存储在数据库中供前端查询。 🔍 核心概念 概念 说明 异步任务(Async Job) 文件解析、OCR、embedding 等耗时操作独立运行,不阻塞主线程。 任务队列(Task Queue) 临时存放待执行的任务,如 Redis、RabbitMQ、Celery。 状态持久化(State Persistence) 将任务状态(pending / processing / completed / failed)写入数据库。 SSE(Server-Sent Events) 一种轻量的实时推送机制,前端可实时接收状态更新。 ⚙️ 实践指南 / 实现步骤 1️⃣ 上传文件接口(只负责入队) @router.post("/upload") async def upload(file: UploadFile, user=Depends(get_verified_user)): file_id = Files.create(file, user.id) # 异步提交任务(Celery、RQ、线程池等) background_tasks.add_task(process_file, file_id) return {"file_id": file_id, "status": "pending"} 2️⃣ 异步任务(后台 worker 执行) def process_file(file_id: str): file = Files.get(file_id) Files.update_status(file_id, "processing") try: parse_and_vectorize(file) Files.update_status(file_id, "completed") except Exception as e: Files.update_status(file_id, "failed", error=str(e)) 3️⃣ 状态查询接口 @router.get("/{id}/process/status") async def get_status(id: str, stream: bool = False): file = Files.get(id) if stream: async def event_stream(): while True: status = Files.get_status(id) yield f"data: {json.dumps({'status': status})}\n\n" if status in ("completed", "failed"): break await asyncio.sleep(1) return StreamingResponse(event_stream(), media_type="text/event-stream") return {"status": file.data.get("status", "pending")} 💻 可运行示例 前端轮询: async function checkStatus(fileId) { let status = 'pending'; while (status === 'pending' || status === 'processing') { const res = await fetch(`/api/files/${fileId}/process/status`); const data = await res.json(); status = data.status; console.log("当前状态:", status); await new Promise(r => setTimeout(r, 1000)); } if (status === 'completed') alert("解析完成!"); } 前端 SSE 实时监听: const evtSource = new EventSource(`/api/files/${fileId}/process/status?stream=true`); evtSource.onmessage = (e) => { const { status } = JSON.parse(e.data); console.log("文件状态:", status); if (status === "completed") evtSource.close(); }; 🧠 原理解释与取舍 模式 特点 适用场景 同步上传+处理 实现简单,但阻塞主线程 小文件、低并发、离线脚本 异步上传+状态查询(推荐) 非阻塞、可恢复、可扩展 Web 应用、后台任务 消息队列驱动 支持分布式任务、重试机制 大规模系统、微服务架构 取舍原则: ...

2025年11月2日 · 2 分钟 · map[name:Jeanphilo]

为什么让前端完成Chat Completion: 一套通用的多模型流式对话架构设计

🔌 为什么让前端执行 Chat Completion:一套通用的多模型流式对话架构设计 副标题 / 摘要 在现代 AI 聊天系统中,很多人会问:为什么不直接在后端调用 OpenAI API? 本文将带你理解一种更灵活的架构——让前端承担推理执行,后端负责调度和状态同步。适合需要支持多模型、本地推理或用户自带 API Key 的开发者。 目标读者 AI 聊天应用开发者 WebSocket / Socket.IO 实践者 想构建多模型、多端协作聊天系统的架构师 🧠 背景 / 动机 传统的聊天后端往往直接在服务器调用 OpenAI API: resp = client.chat.completions.create(model="gpt-4o", messages=messages) 虽然简单,但带来几个现实问题: 所有请求都消耗服务器的 Key,成本高且难追踪; 无法支持用户自定义 Key(BYOK 模式); 无法连接用户本地推理(如 Ollama、LM Studio); 无法切换不同模型或 API Base URL; 前后端状态不同步,不利于流式消息推送。 为了解决这些问题,一些开源系统(如 Open-WebUI、Chatbot-UI 增强版)采用了更灵活的 Socket.IO 双向通信架构。 服务端负责「调度与状态流」,前端负责「执行与回传」。 🧩 核心概念 概念 说明 Socket.IO 基于 WebSocket 的实时双向通信库,支持事件与回调。 event_emitter 服务端向前端广播事件(推送消息/状态)。 event_caller (sio.call) 服务端请求前端执行任务(RPC),并等待前端 callback 返回。 request:chat:completion 一种自定义事件类型,用于请求前端执行 chat completion。 BYOK 模式 “Bring Your Own Key”,用户使用自己的 OpenAI Key 调用 API。 Executor 架构 前端承担推理任务的执行者,后端作为协调者。 🧭 实践指南 / 步骤 1️⃣ 服务端发送调用请求 res = await event_caller({ "type": "request:chat:completion", "data": { "form_data": form_data, "model": models[form_data["model"]], "channel": channel, "session_id": session_id, }, }) 这里的 event_caller 使用 sio.call() 发送事件给指定客户端,并等待 callback 返回。 ...

2025年11月2日 · 3 分钟 · map[name:Jeanphilo]

webSocket深入理解:为什么要保持一个永远在线的连接

🛰️ WebSocket 深入理解:为什么要保持一个“永远在线”的连接? ✨ 副标题 / 摘要 这篇文章带你彻底搞懂 WebSocket: 它和 HTTP 的根本区别、为什么需要“长连接”、连接是如何建立和保持的、以及它在实时应用中的意义。 适合想从“知道是什么”到“理解为什么”的开发者。 👩‍💻 目标读者 Web 前后端初级到中级开发者 想实现实时聊天、AI 流式输出、协作系统的工程师 想从 HTTP 模型过渡到实时架构思维的学习者 🧭 背景 / 动机:为什么这个问题重要? 几乎每个现代 Web 应用都涉及“实时”功能: 聊天对话(ChatGPT、Slack) 实时通知(邮箱、消息提醒) 在线协作(Notion、Google Docs) 数据看板(实时指标、监控) 然而,传统的 HTTP 是“一问一答”的协议, 无法满足服务器主动通知客户端、低延迟双向通信的需求。 WebSocket 的出现,彻底改变了这种单向关系, 让 Web 应用第一次真正拥有了“实时对话”的能力。 🧠 核心概念与术语解释 名称 说明 HTTP 一问一答型协议。客户端发请求,服务器回响应,然后断开。 长连接 一条保持不关闭的 TCP 连接,可反复收发数据。 WebSocket 一种基于 TCP 的双向通信协议,能让服务器主动推送消息。 握手 (Handshake) 客户端通过 HTTP 请求告诉服务器:“我想升级为 WebSocket 协议”。 帧 (Frame) WebSocket 传输的最小数据单元,比 HTTP header 更轻量。 心跳 (Ping/Pong) 定期发送的小数据包,防止连接超时断开。 🪜 实践指南:WebSocket 建立的全过程 1️⃣ 浏览器发起请求(HTTP 阶段) ...

2025年10月31日 · 2 分钟 · map[name:Jeanphilo]

从 Pip 到 UV:一站式 Python 包管理与依赖同步指南

🚀 从 Pip 到 UV:一站式 Python 包管理与依赖同步指南 💡 副标题 / 摘要 想让你的 Python 环境更干净、更快、更可靠?本文将带你从传统的 pip + venv + requirements.txt 迁移到现代的 uv 包管理系统,并教你如何在两者之间无缝同步。 🎯 目标读者 适合 Python 开发者(初学者到中级)、数据科学家、后端工程师,以及希望提升开发环境一致性、减少依赖地狱的读者。 🔥 背景 / 动机 在日常 Python 开发中,我们经常遇到以下痛点: 环境混乱、包冲突; pip install 太慢; 不同机器、团队成员环境不一致; requirements.txt 手动维护麻烦。 而 uv 是一个由 Astral 团队推出的新一代包管理工具, 用 Rust 编写,集成了: 包安装(比 pip 快数倍); 虚拟环境管理; 锁文件机制(可复现环境); 与 PyPI 完全兼容。 一句话:uv = pip + virtualenv + pip-tools + poetry 的融合体。 🧩 核心概念 概念 说明 pyproject.toml 现代 Python 项目的依赖与元信息文件 uv.lock 锁文件,记录所有依赖的精确版本,保证可复现 uv sync 根据锁文件同步环境(自动创建/更新虚拟环境) uv add / remove 添加或删除依赖,并自动更新锁文件 uv export 导出为 requirements.txt,兼容传统 pip 流程 🛠 实践指南 / 步骤 一、从 pip 项目迁移到 uv 假设你已有一个项目: ...

2025年10月31日 · 2 分钟 · map[name:Jeanphilo]