为什么能 Ping 通却 SSH 不通？一次“假 SSH 真 VNC” 的排查过程 副标题： 从连接被拒到协议识别，带你彻底理解 TCP、SSH 与 VNC 的区别 阅读时长： 7 分钟 标签： 网络排查、SSH、VNC、Linux、远程连接 SEO 关键词： SSH连接失败、kex_exchange_identification、VNC端口5905、RFB 003.008、SSH vs VNC 🎯 目标读者 Linux 使用者、开发者、服务器维护人员 想学习网络排错思路的中级工程师 对 SSH/VNC 协议机制有兴趣的读者 💡 背景与动机 你是否遇到过这样的情况： “服务器能 ping 通，但 SSH 连不上？” 这类问题很常见，尤其是在多服务（SSH、VNC、HTTP）混跑的远程主机上。 本文通过一次真实案例，展示从“SSH 连接失败”到“发现端口跑的是 VNC”的完整分析过程。 🔍 问题现象 执行命令： ssh chenhm@101.6.142.82 -p 5905 输出： kex_exchange_identification: Connection closed by remote host Connection closed by 101.6.142.82 port 5905 尝试 ping： ping 101.6.142.82 能通，没有丢包。 于是我们知道： ...

🧠 Bengio 风格的机器学习任务说明文档：从研究到工程的技术规范指南 副标题： 如何编写一份可复现、可解释、可比较的模型微调任务说明文档 —— 来自 Yoshua Bengio 的研究方法论 阅读时长： 10 分钟 标签： 机器学习文档结构 模型微调 技术规范 深度学习实践 适合读者： 中高级 ML 工程师、研究员、技术写作者 一、为什么需要这样的文档？ 在机器学习项目中，我们经常遇到这样的情况： 团队完成了一个模型微调实验，但几个月后再回头看，没人能完全复现结果，也不清楚为什么要采用某个学习率或 LoRA 层。 Yoshua Bengio（深度学习三巨头之一）早在 Montréal Institute for Learning Algorithms (MILA) 就提出了一个理念： “一个机器学习研究或工程任务的文档，必须能让他人完全重现结果并理解背后的设计动机。” 这就是后来被称为 Bengio-style Machine Learning Project Report Structure 的经典模板，被 Google Research、Meta AI、OpenAI 等广泛采用。 二、Bengio 风格模板的核心思想 项目 内容 来源 Yoshua Bengio，《Deep Learning Research Practice Notes》 目标 确保机器学习实验 可复现、可理解、可比较 适用场景 模型微调、对比实验、学术研究报告、内部技术说明 优势 逻辑清晰、结构统一、可直接转化为论文或内部白皮书 三、标准结构（适用于四个模型微调任务） 以下是 Bengio 风格文档的经典九个部分： ...

🧱 从零到生产：如何优雅地设计 ORM 层管理（以 SQLAlchemy 为核心） 本文将带你从数据库表结构出发，构建一套高内聚、低耦合的 ORM 层架构。 目标：让你的 Flask / FastAPI 项目在数据访问上既简洁又稳健。 一、为什么要重视 ORM 层设计？ 很多项目初期只是“先能跑”，直接把 SQL 写在控制器里，但很快就会出现： 业务逻辑和 SQL 混在一起； 表关系复杂，维护困难； 想复用查询逻辑很麻烦； 迁移到别的框架（Flask → FastAPI）代价大。 ORM 层（Object Relational Mapping）是数据库与业务逻辑之间的 抽象桥梁， 一个好的 ORM 层能让你只关心对象，不用反复写 SQL。 二、项目场景：招标信息数据系统 我们以一个真实业务为例： 爬取各网站的招标公告，保存为结构化数据，并生成统计看板。 目标数据库实体 表名 功能 tender_info 公告基本信息 tender_attachments 公告及变更文件 tender_organization 招标机构与联系方式 tender_statistics 每日/月/年统计信息 三、ORM 层设计思路 🧩 分层原则 层级 作用 代码位置 Model 层 ORM 模型定义，对应数据库表结构 models.py Repository 层 封装 CRUD 逻辑（数据库操作） repository.py Service 层 业务逻辑层（聚合多个仓库逻辑） service.py API 层 控制器/路由接口 Flask/FastAPI 视图文件 这种分层让你做到： ...

🚀 在 Ubuntu 上让 frp 内网穿透服务开机自启：完整指南 副标题 / 摘要 通过 systemd 将 frp（Fast Reverse Proxy）设置为系统服务，实现稳定、安全、可监控的开机自动启动方案，避免每次手动运行。 阅读时长：8 分钟 标签：frp、内网穿透、systemd、自启、Linux、Ubuntu SEO 关键词：frp 开机自启、Ubuntu frp 配置、frpc systemd、frps 服务端启动、内网穿透配置 元描述：手把手教你在 Ubuntu 上使用 systemd 将 frp（frpc / frps）设置为开机自启服务，附配置文件模板与常见问题排查。 🎯 目标读者 适合： 想在云服务器上部署 frps 的开发者 想让家中/办公内网机器长期稳定穿透的中级 Linux 用户 DevOps / 自建服务爱好者 🧩 背景与动机 许多开发者使用 frp 实现内网穿透，让内网服务（如 SSH、Web、NAS）可以安全地从外部访问。 问题是：手动运行 ./frpc -c frpc.ini 既麻烦又不稳定，机器重启后容易忘记启动。 因此，我们希望通过 systemd 服务 实现“自动随系统启动 + 失败自动重启 + 集中日志管理”的效果。 💡 核心概念 frps / frpc：frp 的服务端与客户端可执行程序。 systemd：现代 Linux 系统的服务管理器，用于定义和控制后台服务。 unit 文件：定义服务的配置（如启动命令、依赖、重启策略）。 🛠️ 实践步骤指南 1️⃣ 安装与准备 将二进制文件与配置文件放入系统路径： ...

📝 Windows + WSL2 端口转发教程（访问 Flask 5000） 前提条件 你正在使用 WSL2（Ubuntu 或其他 Linux 发行版） Windows 主机能访问局域网（Wi-Fi 或以太网） Flask 服务在 WSL2 中运行，并监听： app.run(host="0.0.0.0", port=5000) ⚠️ host="0.0.0.0" 必须，否则外部无法访问 第 1 步：确认 WSL2 的 IP 在 WSL2 中运行： ip addr show eth0 你会看到类似： inet 172.26.209.37/20 记下 inet 后面的 IP（本例是 172.26.209.37），这是 WSL2 内部 IP。 第 2 步：打开 PowerShell（管理员模式） 按 Win + X → 选择 Windows PowerShell (管理员) 确认管理员权限，必要时允许 UAC 提示 第 3 步：设置端口转发 在 PowerShell 中执行以下命令，将 Windows 的 5000 端口转发到 WSL2： ...

在局域网访问 Windows WSL2 上的 Git Bare 仓库 在开发中，我们经常需要在多台电脑之间共享 Git 仓库。如果你在 Windows 上使用 WSL2，并且想在同一局域网的其他电脑访问 WSL2 上的 Git bare 仓库，本文将一步步教你实现。 1. 在 WSL2 创建 Git Bare 仓库 打开 WSL2 终端，进入你想存放仓库的目录，执行： git init --bare my_project.git my_project.git 是 bare 仓库，不含工作区，仅用于推送和拉取。 bare 仓库就像远程仓库一样，可以被克隆和操作。 2. 配置 WSL2 的 SSH 服务 为了让其他电脑访问仓库，需要通过 SSH 访问 WSL2。 安装 SSH 服务： sudo apt update sudo apt install openssh-server -y 启动 SSH 服务： sudo service ssh start 检查 SSH 服务状态： sudo service ssh status 默认端口是 22，可以在 /etc/ssh/sshd_config 修改。 3. 获取 WSL2 IP 地址 在 WSL2 终端运行： ...

🚀 使用 wrk 对接口进行高性能压力测试（超详细教程） 本文介绍如何在 Ubuntu 环境中使用 wrk 对后端接口（如 Flask / FastAPI / Spring Boot 等）进行高并发压力测试，并结合结果分析性能瓶颈。 🧰 一、什么是 wrk？ wrk 是一个现代化、高性能的 HTTP 压测工具，由 C 语言编写，具有以下特点： 高并发能力强：支持成千上万的并发连接 支持多线程：充分利用多核 CPU 可自定义 Lua 脚本：适合复杂场景（如自定义请求头、Body、Token 等） 比 Apache Benchmark (ab) 更轻量、更快、更稳定 ⚙️ 二、安装 wrk 在 Ubuntu / Debian 上安装： sudo apt update sudo apt install wrk -y 验证安装是否成功： wrk --version 输出类似： wrk 4.2.0 [epoll] 表示安装成功 ✅ 🧪 三、快速开始压测 假设你的服务运行在： http://192.168.1.224:5000/api/tenders 运行： wrk -t4 -c100 -d30s http://192.168.1.224:5000/api/tenders 参数说明： 参数 含义 -t4 启动 4 个线程（利用多核 CPU） -c100 模拟 100 个并发连接 -d30s 持续压测 30 秒 最后一个参数 目标 URL 📊 四、示例输出结果解读 假设输出如下： ...

🌿 简化 Git 分支工作流（个人 / 小团队） 本工作流基于 Git Flow 精简而来，适合个人或小团队，既规范又不复杂。 🚀 1. 主分支（长期分支） main 永远保持稳定、可发布的状态。 部署到生产环境的代码都来自这里。 对于小团队，通常只需要 main，不需要维护 develop。 🛠️ 2. 功能开发（Feature Branch） 分支命名：feature/<功能名> 用途：开发新功能，完成后合并回 main。 示例： feature/login-api feature/user-profile 流程： # 从 main 创建功能分支 git checkout -b feature/login-api main # 开发完成后，合并到 main git checkout main git merge feature/login-api git branch -d feature/login-api 🐞 3. Bug 修复（Bugfix Branch） 分支命名：bugfix/<问题名> 用途：修复测试或开发环境的 bug。 示例： bugfix/fix-login-redirect 流程同 feature 分支，完成后合并回 main。 🔥 4. 紧急修复（Hotfix Branch） 分支命名：hotfix/<问题名> 用途：生产环境出现严重问题时的快速修复。 示例： ...

在本地使用 Git 裸仓库实现开发环境和测试环境隔离 在全栈开发的过程中，我们常常遇到一个问题：开发环境和测试环境如何隔离？ 很多人第一反应是用 GitHub 或 GitLab 来托管代码，但如果项目涉及隐私，不方便放在公共仓库，那该怎么办呢？ 其实，Git 是分布式的，我们完全可以在 本地电脑上建立一个“裸仓库 (bare repo)”，当作“远程仓库”来用，从而实现 开发环境 → 测试环境 的代码迁移和同步。 什么是裸仓库 (bare repository) 普通 Git 仓库（git init）包含 工作区 + .git 元数据，可以直接编辑文件。 裸仓库（git init --bare）只有 Git 的版本信息，没有工作区，不能直接编辑文件，通常作为 远程仓库 来存储和同步代码。 简单理解： 开发仓库：我在这里写代码。 裸仓库：我用来存放代码历史，作为远程同步点。 测试仓库：从裸仓库克隆出来，模拟运行环境。 步骤一：创建裸仓库 在本机某个目录（比如 ~/.repos）下创建裸仓库： mkdir -p ~/.repos cd ~/.repos git init --bare scrapy.git 这样你得到一个路径 ~/.repos/scrapy.git，它就是本地的远程仓库。 步骤二：在开发仓库里添加远程 假设你的开发仓库在 ~/scrapy： cd ~/scrapy git remote add local ~/.repos/scrapy.git 检查一下远程是否添加成功： git remote -v 输出类似： local /home/gong/.repos/scrapy.git (fetch) local /home/gong/.repos/scrapy.git (push) 说明配置成功。 ...

Python 日志与追踪 Python 日志追踪实践 结构化日志与追踪 副标题/摘要： 结合 logging + OpenTelemetry 实现结构化日志并把 trace_id 注入日志，便于在生产环境串联调用链与定位问题。 TL;DR： 设置 json 格式日志并通过 OpenTelemetry 在每条日志里注入 trace_id/span_id。关键步骤：安装依赖 → 配置 logging（JSON）→ 配置 TracerProvider → 用 Filter 从当前 span 提取 trace 信息并添加到日志记录中。 目录 背景与动机（为什么需要） 关键概念与术语解释 环境与依赖（安装命令） 逐步实战示例（可直接运行） 原理与实现要点 常见问题与注意事项 最佳实践总结 结论与下一步建议 可视化建议 参考与延伸阅读 可复制示例代码 背景与动机（为什么需要） 现代后端服务分布式部署后，单靠文本日志很难把一次请求链路从入口到后端串起来。结构化日志（JSON）便于聚合与查询；而分布式追踪（tracing）给出调用链与 span 信息。二者结合能快速定位延迟与错误根因：日志告诉你“发生了什么”，trace 告诉你“这个请求经过了哪些服务/操作”。 关键概念与术语解释（简明） 日志（Logging）：程序运行时的事件记录，通常按级别（INFO/ERROR）输出。 结构化日志：以 JSON 等结构化格式输出，便于机器处理与检索。 Trace/Span：一次分布式操作（trace）由若干子操作（span）组成，span 含有 trace_id 与 span_id。 Context Propagation：在不同服务/线程/协程中传递 trace context 以串联调用链。 环境与依赖（列出安装命令） 推荐环境：Python 3.8+ 安装依赖： pip install python-json-logger opentelemetry-api opentelemetry-sdk ...