Posts

我为什么想做 LinkNest 现在一个人手里往往不止一台设备：电脑、手机、平板、服务器，甚至还有临时使用的开发机。 真正麻烦的不是“能不能传一个文件”，而是这些设备经常处在不稳定的网络环境里： 家里、学校、实验室的网络来回切换 DHCP 让设备 IP 经常变化 两台设备不一定同时在线 大文件传到一半可能因为网络波动中断 云服务器上已经有资源，但缺少一个清晰的索引和拉取入口 所以我想做一个项目，暂时叫 LinkNest，中文名是 链巢。 它不是想重新做一个普通网盘，也不是简单复制一个局域网传输工具，而是想在“局域网直连”和“云端资源池”之间做一个更轻量、更适合个人和小团队自部署的传输系统。 LinkNest 想解决什么问题 LinkNest 的核心目标是：在动态网络环境里，让多台设备依然能通过稳定身份、在线状态和云端资源索引完成可靠传输。 我最想先解决的是这几件事： 设备身份不要绑定 IP 设备第一次启动时生成稳定的 Device ID，后续即使 IP 变了，服务端也知道它还是同一台设备。 服务端维护设备在线状态 客户端通过 WebSocket 发送心跳，服务端记录设备名、设备类型、当前局域网 IP、端口和最后在线时间。 云端保留资源索引 文件上传后，服务端记录文件元数据。另一台设备即使不和上传设备同时在线，也能从云端资源列表里拉取文件。 大文件支持断点续传 上传和下载按分片执行，中断后只补缺失分片，并通过 hash 校验完整性。 后续优先局域网直连 当两台设备在同一局域网内时，优先走直连；不可达时再用云端作为兜底。 第一阶段先做小闭环 这个项目不能一开始就把所有客户端、P2P、WebRTC、UI 和云存储都堆上去。 我现在更倾向于先做一个能跑通的最小闭环： Go 服务端基础框架 设备注册接口 Go CLI 客户端原型 Device ID 生成和持久化 WebSocket 心跳 云端设备列表 API IP 变化后设备身份不变、在线状态能更新 这个阶段完成后，项目至少能证明一个关键点： 设备身份和网络地址可以解耦，动态 IP 不应该让设备关系失效。 MVP 版本会包含什么 在第一阶段之后，MVP 会继续往“真正能传资源”的方向推进： 用户注册和登录 多设备绑定到同一账号 在线设备展示 文件上传到云服务器 云端资源列表 从云端下载文件 大文件分片上传 断点续传和 SHA-256 校验 基础 Web UI 或客户端界面 这个版本的定位很明确： 先让一台设备上传资源，另一台设备可以稳定地看到并拉取。等这个链路跑稳，再去做局域网发现、直连传输和更复杂的调度。 ...

为什么要做这个项目 我想搭一个真正能长期使用的个人博客，而不是只在本地打开一次主题示例页面。 对我来说，一个博客站至少要满足几件事： 能稳定写文章 能把已有项目经历整理上线 后续还能继续改样式、改结构、改部署，而不是每次重头来一遍 所以这次项目真正做的，其实不是“套一个主题”，而是把博客从本地示例一步步整理成一个能持续维护的站点。 站点是怎么搭起来的 我选的是 Hugo + PaperMod 这套组合。 原因比较直接： Hugo 适合写静态博客 Markdown 写文章效率高 部署简单 和 GitHub、Cloudflare 这类工具链很容易接起来 PaperMod 则帮我先解决了： 首页模式 文章页结构 目录（TOC） 标签页 一些基础 SEO 元信息 这样我一开始就不用从零写模板，而是先把内容结构和部署链路跑通。 我做了哪些关键整理 1. 清掉官方示例内容 主题自带的示例页更适合演示功能，不适合直接变成自己的博客。 所以我先做的不是“加功能”，而是： 清理默认示例内容 只保留自己的 posts 结构 创建文章 archetype 把站点导航收成更适合个人博客的样子 这一步很重要，因为它决定了这个站到底是“演示模板”还是“个人项目”。 2. 把已有项目经历转成文章 博客不能只有壳子，没有内容。 所以后面我把自己已有的项目经历逐步整理成文章，例如： dotfiles 仓库整理与同步 Kubernetes 静态网页部署实践 在这个过程中，我也发现一件事： 项目笔记和博客文章其实不是同一种写法。 笔记更偏内部记录 博客更偏对外表达 所以后来我会先把项目整理成笔记，再把它改写成更适合公开阅读的博客版本。 3. 给站点补上独立的 Gallery 照片模块 后面我又做了一件和普通文章不太一样的事：给站点加了一个独立的 Gallery 页面。 我不想把照片简单塞进博客文章里，因为两者的阅读方式完全不同： 文章适合连续阅读 照片更适合按组浏览，再点进去细看 所以这次照片模块采用的是另一套结构： 右上角导航新增 Gallery 页面按日期分组 每个日期组是一张独立卡片 卡片顶部显示日期、出处、作者 组内照片直接用缩略图网格展示 点击单张照片进入独立详情页 单图详情页也不是普通博客正文结构，而是： ...

项目目标 这次我想做的不是“写一个网页”，而是把一条完整的部署链路走通： 写一个最小静态网页 用 Docker 打包成 nginx 镜像 把镜像推送到 Docker Hub 在云上的 Kubernetes 集群里部署 最后通过 SSH 隧道在本地浏览器访问 项目本身不复杂，但它把前端、容器、镜像仓库和 K8s 串在了一起。对我来说，这比单独学某一个命令更有价值。 我做了哪些事情 整个过程大致分成五步： 编写欢迎页：HTML、CSS、JavaScript 编写 Dockerfile，把静态资源打包进 nginx 编写 deployment.yaml 和 service.yaml 在本地 WSL 安装并验证 Docker 环境 把镜像推送到 Docker Hub，再部署到华为云 Kubernetes 最后访问路径也打通了： 服务器本机验证：curl http://127.0.0.1:30523 本地浏览器访问：http://127.0.0.1:8080 使用 SSH 隧道：ssh -N -L 8080:127.0.0.1:30523 huaweiyun 核心工作流 1. 本地构建镜像 在 WSL 中完成镜像构建和推送： cd /mnt/d/codex/static-k8s-demo docker login -u <dockerhub-user> docker build -t leoduya/static-web-demo:latest . docker push leoduya/static-web-demo:latest 这里最关键的是把网页内容和 nginx 一起打进镜像，这样 Kubernetes 节点只需要拉镜像，不需要再手动拷贝网页文件。 ...

为什么要做这个项目 每次换机器、重装系统或者迁移开发环境时，最烦的往往不是装软件，而是把一堆零散配置重新凑起来： shell 配置 Vim / Neovim 配置 Git 配置 SSH 配置 这些文件平时分散在各处，真到迁移时就会发现： 有的改动忘了记 有的文件路径不统一 有的手动复制很容易漏 所以我给自己定了一个目标：把常用配置整理成一个 dotfiles 仓库，并且让它能在新机器上快速部署。 这个项目的目标不是“备份几个隐藏文件”，而是把环境管理变成一个可维护的流程。 这次做了什么 这次项目包含了几个明确步骤： 收集现有配置文件 设计 dotfiles 目录结构 编写安装脚本 初始化 Git 仓库并同步到 GitHub 补 README 和使用说明 最终成果不是“多了一个文件夹”，而是得到了一套可以复用的环境管理方式。 我是怎么组织这个仓库的 核心思路不是把所有文件乱丢进去，而是按类型组织： shell nvim / vim git ssh 这样做的好处是： 以后查找配置更快 哪一类配置要迁移，一眼就能找到 后续做安装脚本和备份逻辑也更自然 这个项目的关键不在“文件数量”，而在于结构是否清晰。 安装脚本为什么重要 如果只是把配置文件备份到 GitHub，其实还不够。 真正有价值的是：在一台新机器上，能不能快速恢复出接近原来的环境。 所以我写了一个安装脚本，负责做三件事： 创建符号链接 备份已有文件 支持安装和卸载 这就把“手动复制配置”变成了“运行一个脚本恢复环境”。 同步到 GitHub 的意义 这一步的意义不只是备份。 把 dotfiles 放进 GitHub 后，我获得了三个好处： 配置有版本历史 可以在多台机器之间同步 新环境部署时不需要从零开始整理 这次仓库也顺利创建并推送成功，整个流程跑通之后，环境管理这件事就从“临时救火”变成了“可维护工程”。 ...