DaydreamNation

本科回忆录 1

Sun, 12 Apr 2026 00:00:00 GMT

本科回忆录 1#

还有两个月我就要毕业了，有闲心的时候开始整理我的本科四年生活，这四年有不少有意思的好玩的事情。担心之后忘记，所以准备记录在我的博客里，在赛博空间留下痕迹。这一栏目会按照时间排序。

大一入学前22年的暑假，我和陈茜去喝了北京的几家酒吧，算是第一次开始了解鸡尾酒。那段时间对喝酒还挺感兴趣的，回来之后就忍不住开始自己瞎调。一开始的理解其实非常粗糙，本质就是基酒兑饮料，能喝就行，完全谈不上什么风味结构之类的东西。

上了大学之后，我在朋友圈看到一个高中同学在学校里摆鸡尾酒摊卖酒，也想自己搞一个。于是我就拉上我的大学舍友刘乐，开始琢磨着在北工大也搞一个。最开始我是在校园墙发帖子摇人，结果还真有人来跟我交流。有个比我大一届的朋友告诉我，北工大其实已经有一个人在做鸡尾酒摊了，而且规模还挺大，群里都有好几百人。

他们当时做得挺大规模的，每天晚上在操场出摊，人一直很多，后面甚至还搞了个投影屏在那放电影，已经有点开酒吧的感觉了。不过没过一阵子就开始被保安制裁了。

但不管怎么说，还是决定自己试试。于是我开始做酒。当时用的配方基本都是从小红书现学的几个经典款：古典、威士忌酸、Highball 这些。基酒选得很劣质，基本就是白金宾、百加得这种最便宜的，调酒技术可以说是灾难级（蛆粪等级）。但靠着我和刘乐卖力吆喝，这个摊子最后居然回本了，甚至还赚了几十块钱。

我手写的酒单，之后有个PS做的

中间最难绷的事情是。有天晚上我和刘乐在南操场门口免费送鸡尾酒，结果碰到我们专业的同学。上来第一句话就是问我们：“这个喝了不会中毒吧？”（具体原话记不太清了，大概是这个意思。）但问完之后她还是拿了一杯走了（教父），至于最后喝没喝，我也不知道。到现在那瓶用来调的蒂萨诺杏仁利口酒还在我宿舍柜子的鞋柜里。

这个酒摊其实没做几天就不了了之了。原因很简单，就是懒，后面就没有再继续折腾。但对鸡尾酒的兴趣倒是一直保留到了现在，算是一个鸡尾酒启蒙吧，当时把小红书里的简单鸡尾酒制作帖子看了一遍，认识了不少经典鸡尾酒，但基本上就是记住配方，对酒的结构没有认识。现在再回头看，当时卖的那些酒确实是烂得离谱，但作为一段经历来说，还是挺好玩的。

出摊的一晚我在宿舍的吧台

我的垃圾基酒们，甚至还有一个可乐桶

喝酒快乐时光

劣质预制柠檬汁

Git 忽略规则踩坑：为什么 .gitignore 有时候完全没用？

Wed, 08 Apr 2026 00:00:00 GMT

Git 忽略规则踩坑：为什么 .gitignore 有时候完全没用？#

在项目刚初始化的时候，我犯了一个非常经典的错误：

👉 没有提前写 .gitignore，直接把整个仓库 commit + push 了。

结果就是：

log、cache、dist 全部进仓库
仓库迅速变脏
后面再加 .gitignore，发现——完全没用

这篇就是一次完整的踩坑复盘。

🧨 问题复现#

典型流程如下：

Terminal window

1
git init
2
git add .
3
git commit -m "first commit"
4
git push

然后你才意识到应该加：

1
*.log
2
cache/
3
dist/

接着你：

Terminal window

1
rm out.log
2
git add .
3
git commit -m "remove log"
4
git push

然后程序一运行，又生成：

1
out.log

你再看：

Terminal window

1
git status

👉 它居然还在被跟踪（modified）

❗核心误区#

很多人会误以为：

“我都加 .gitignore 了，为什么 Git 还管这个文件？”

实际规则是：#

.gitignore 只对未被跟踪的文件生效

🧠 Git 的真实逻辑#

Git 只关心一件事：

这个文件 有没有被跟踪（tracked）过

一旦某个文件进入过版本库：

它就变成 tracked file
.gitignore 对它 完全失效

🔍 两种常见情况对比#

情况 1：你只是删除了文件 ❌#

Terminal window

1
rm out.log
2
git add .
3
git commit

结果：

Git 认为你只是“删除了一个 tracked 文件”
下次再生成 out.log：

Terminal window

1
git status

输出：

1
modified: out.log

👉 仍然被跟踪

情况 2：你取消了跟踪 ✅（正确做法）#

Terminal window

1
git rm --cached out.log
2
git commit -m "stop tracking out.log"

结果：

Git 不再跟踪这个文件
.gitignore 开始生效

再次生成：

Terminal window

1
git status

👉 什么都没有（被 ignore）

🚀 一步到位的修复方案（推荐）#

如果你已经“污染”了仓库，最稳的方式是：

Terminal window

1
git rm -r --cached .
2
git add .
3
git commit -m "apply gitignore properly"
4
git push

这一步做了什么？#

清空所有已跟踪文件（仅索引，不删本地）
重新按 .gitignore 规则添加
让 ignore 真正生效

🧪 自检方法（强烈建议）#

运行：

Terminal window

1
git status

正常情况：#

out.log 不会出现

异常情况：#

1
modified: out.log

👉 说明它还在被跟踪

⚠️ 一个非常容易忽略的坑#

.gitignore 写错路径：

1
log/

但实际目录是：

1
logs/

或者你只写了：

1
log/

但文件是：

1
out.log

👉 需要写：

1
*.log

🧹 如果你想连历史一起清掉（进阶）#

如果这些 log 已经进入历史（导致仓库很大），需要：

Terminal window

1
git filter-repo --path-glob "*.log" --invert-paths
2
git push origin --force --all

⚠️ 注意：

会重写历史
团队协作需要提前沟通

📌 最终总结#

记住三句话就够了：

.gitignore 不会影响已被跟踪的文件
删除文件 ≠ 取消跟踪
必须用 git rm --cached 才能真正“忽略已提交文件”

🧩 一句话理解本质#

Git 关心的是“这个文件是否被记录过”，而不是“这个文件现在存不存在”。

✍️ 后记#

这个坑几乎所有人都会踩一次。

但一旦理解了 Git 的 tracking 机制，其实逻辑非常简单：

👉 ignore 是入口规则，不是清理工具。

大连周末散心：喝喝

Sun, 29 Mar 2026 00:00:00 GMT

大连周末散心：喝喝#

大连作为一个在东北、但性格很不东北的城市，有不少还不错的鸡尾酒吧。这次去也尝试了两家，总的来说价格比北京便宜，出品也还不错，没有特别惊喜，但也没有很失望。

EXIT#

小红书上很火的一家店，装修是包豪斯风格。七点开门，我和陈茜七点半到的时候，就只剩最后两个吧台座位了，而且还是两个不挨着的。后来遇到一个一个人来的老哥，人挺不错，挪了一个座位出来，才让我俩坐进去。

这家酒吧主要还是来打卡的小红书女用户比较多，点酒单里特调的人也偏多。他们家的酒单很有意思，只有 1-8 八个数字，对应八款酒，价格统一都是 75 元。前面几款基本都是果味偏重的小甜酒，我不太爱喝这类，所以没啥太多好说的，但难得来一次，还是尝试了几款特调。

#4#

这款酒是朗姆 base，加了一些雪莉，再配上青提、青柠的果味酒。酒精感很淡，果味很浓，不难喝，但我没喝出来什么特别的地方。

#6#

用了烧酒的一款长饮，蜜瓜味很浓，也是一款没什么酒味的小甜酒。

两款特调

喝完两款特调后，终于还是忍不住回到舒适区了。

Gimlet#

一杯挺有意思的 Gimlet，base gin 用的是 Sipsmith Sloe Gin。相比普通干金酒，杜松子味确实没有那么重，但酒本身的风味也没有特别被凸显出来，总的来说是一杯合格的出品。

Gimlet

Bamboo#

用了曼齐诺和 Tio Pepe 两款酒，喝上去比我自己做的涩感更轻。之前我自己做的时候用的是杜林干味美思，总感觉涩感很重，但也不算难喝。喝他们这杯的时候，明显觉得涩口感轻了不少，不知道是配方的原因，还是干味美思本身的原因。

Tidal#

也是一家在小红书里号称“大连第一”的酒吧，环境也很棒，酒吧外面摆满了空瓶的季之美。

七点开门，我和陈茜七点零五就到了。因为还要赶晚上九点十五的晚班机回北京，这里不得不夸一下大连周水子机场，修在市区里，机场也不大，从市区酒吧打车过去也就二十分钟，完全不用太早到。九点的飞机，七点半我还在喝鸡尾酒，这在北京肯定是做不到的。

不过因为时间确实不长，所以这里只喝了两杯。

两款特调

Twentieth Century#

一款很有意思的短饮鸡尾酒，Gin base，带有可可——我喝起来更像白巧克力——和柑橘的香气。可可这个味道非常有意思，也是我第一次在鸡尾酒里喝到，挺好喝。

White Gimlet#

也是这里的一杯特调，但我不太喜欢。总之就是在 Gimlet 里加上了很浓的茶味，不是那种茶香，而更像是加了浓缩茶，茶味几乎盖住了所有鸡尾酒本身的味道，一般般。

总结#

总之，喝得很开心，但感觉这边的老板没有北京酒吧的老板好玩。

大连周末散心：吃吃

Thu, 26 Mar 2026 00:00:00 GMT

大连周末散心：吃吃#

上班实在没劲，于是请了周五一天假期给自己凑了一个周末散心。24年的夏日也来了大连旅游，但那一次是暑期的七月旺季，去哪哪都人山人海，还被出租车司机待到贵价宰客的海鲜店，实在没有太多好的经历。于是这一次来打算不去什么打卡点，就吃吃日料喝点小酒，现在看来是一个正确的选择。聊到吃在大连一定离不开日料，据说大连有一千多家日料店，水平也相当不错，很卷，而且价钱也比北京更实惠，这次来吃了三家日料店，吃的尽兴。

拉面：面道场#

这家店是小红书上推荐的一家店，主营拉面，店面就开在大连的日料一条街中间。人气很火爆，我们在工作日周五的中午 11:30（开门时间）进店，已经有几桌坐下了，过了十五分钟基本就只能等位。

我和陈茜点了鱼介和咖喱的沾面，面条很筋道，也很香。口味上我感觉也稍微为中国人做了些调整，并没有很油腻或者很咸。赶了早班机的我们吃完之后，就美美打车回酒店晕碳睡去了，一觉睡到三点才起。

对这家店的评价，我觉得和北京我爱吃的日出拉面也没啥区别，挺正宗的。更讲究的口味我也吃不太出来了，总之就是吃得过瘾尽兴，而且还不贵。（30一碗）

两份拉面

烧鸟：烧鸟屋#

大连一个不知名小街边的烧鸟夫妻店，室内装潢是非常经典的日式居酒屋风格。来之前，我还特意打电话问了店家晚上会不会排队，店家很肯定地说不用。等我到了之后，事实也确实如此，整个店就我一桌客人。

这家的烧鸟菜单就是常规的经典烧鸟，比较稀少的内脏和特殊部位并没有提供，味道也是中规中矩。老板娘不算太热情，但基本的服务都有。价格也比较美丽，能吃得很爽。美中不足的是，菜单上提供了朝日扎啤，我本来以为可以喝个爽，但似乎啤酒冰镇得并不是很足，没有到达最好的口感。

这家店我和陈茜吃得都有点撑了，也就花了 200 元。在北京，同档次的一顿怎么找也得三百多了，性价比还是不错。

提灯

鸡肉串和啤酒

海鲜饭：人生渔鲜饭#

一家主打海鲜饭的小店，店面很小，基本都是一个人的位置。菜单也很简洁，只有几种海鲜饭和炙烤三文鱼、牛肉饭之类的几样。我点了三文鱼、海胆和甜虾的三拼饭，新鲜程度没得说，都很爽口，应该是老板当天采购的。

分量不算小，也不算大，对晚上还要去酒吧喝酒的安排来说刚刚好。我一直盼着吃到真正好吃的生海胆，但这次还是让我有点失望。在日本小店或者在大连小店，都没有让我品尝到特别惊艳的海胆。或许海胆就是如此设计吧。我想象中它应该是鲜甜可口的，但那种吃进嘴里黏黏的感觉，总让我想到秋葵中间的粘液。

不过总之，海鲜饭加点酱油，配上米饭，还是很美味的，好评！

海鲜饭

Gimlet 的新尝试：薄荷金酒与利10号的对话

Mon, 16 Mar 2026 00:00:00 GMT

Gimlet 的新尝试：薄荷金酒与利10号的对话#

调酒如同写作，每一次配比的微调，都是对风味与平衡的思考。今天，我再次尝试用二月份旅行时带回的二世谷蒸馏所薄荷味金酒制作 Gimlet。其实，这只金酒我之前已经尝试过两次。

第一次，我用了 30ml 常规伦敦干金搭配 15ml 薄荷金酒。薄荷的风味并不突出，反而被杜松子的香气掩盖。第二次，我吸取了上一次的经验，全量使用薄荷金酒。这次薄荷风味非常浓烈，喝下去甚至让嗓子感到一丝冰凉。如果追求饱满的薄荷感，这是一个不错的选择，但相对缺乏平衡。

今天，我尝试了 30ml 薄荷金酒搭配 15ml 利十号的组合，结果是这几次最满意的一杯。通过这几次实验，我也开始思考经典鸡尾酒配方的新方式——将基酒拆解为“常规基酒”与“风味基酒”，在保留酒体骨架的同时，引入更多个性化风味。

我在初识调酒时，看网上视频里的调酒师们，总是用这样的方式来展现他们对于鸡尾酒的理解，于是照猫画虎的也学着这样做，但是有些时候还不如完全按照经典配方好喝。在这次尝试之后，我开始更认真地思考“将基酒拆解为传统基酒与风味基酒”的操作。表面上，这看似只是把经典配方稍加修改：把原本的单一金酒分解为“骨架酒”和“风味酒”，再进行比例调节。然而，真正的价值不在于形式上的变化，而在于对风味层次的理解与掌控。

思考的核心在于：

传统基酒承担了鸡尾酒的结构和重量，是喝进嘴里后的质感。
风味酒则提供个性化香气与味觉印记，让经典配方产生新的风景。

关键在于要找到能让人感到这杯酒还是Gimlet，但是特色风味也很突出的临界点。

配方概览#

添加利10号：15ml
二世谷蒸馏所薄荷味金酒：30ml
青柠汁：15ml
单糖浆：一吧勺

调制步骤#

准备Shaker，加入利10号与薄荷金酒。
加入新鲜青柠汁。
添加单糖浆，轻轻搅拌。
加入冰块，用摇酒器摇匀。
过滤入预冷鸡尾酒杯。
青柠皮喷香。

风味思考#

添加利10号：骨架，深度，微苦，柑橘香气。
薄荷金酒：清爽、香气，带来风味。
青柠汁：酸度拉升层次感。
单糖浆：平衡酸度，柔化酒体。

总结#

这款 Gimlet 是经典与创新的结合。
每一次调制都是实验，每一次尝试都值得记录。

浅谈柯达电影卷5219：一款“全能”的胶卷

Fri, 13 Mar 2026 00:00:00 GMT

浅谈柯达电影卷5219：一款“全能”的胶卷#

趁着北京的雪景，我终于把放在相机里小半学期的柯达5219拍完了。冲扫后的底片效果超出了我对这卷胶卷的预期，让我对它有了更深的认识。

作为柯达彩色负片系列中的灯光卷，5219在很多人的印象里偏蓝，尤其是在日光下。然而，这次的拍摄却让5219的偏蓝色调与雪天意外契合。雪地在冷色调的渲染下显得格外洁白，仿佛连空气都透着透明的寒意；阴天微弱的光线在画面中形成柔和的阴影，让每一片雪花都仿佛有了质感。这样的效果，比我想象中更有电影感，也让普通的雪景显得生动而不单调。

下雪的四教天台

5219给我最深的印象是它的“全能”。在ISO500下，它就能展现出细腻而丰富的画面质感；据说它是目前唯一可以稳定迫冲至ISO1600的彩色负片，这意味着即便在光线不足的室内或傍晚，也能拍出清晰、干净的照片。更难得的是它的宽容度：暗部细节丰富，即便是被雪反射的高光区域，也没有出现过度曝光或细节丢失的情况。

四教天台

拍摄这卷5219的过程，也让我重新感受到胶片的魅力。在雪地中，按下快门的瞬间，白色的世界仿佛被定格，每一张照片都带着微微的冷意与静谧感。那种慢慢等待冲扫结果的期待，也让拍摄本身变成了一种仪式感。

总体来说，5219对我而言是一款非常适合日常随手拍的胶卷。ISO500就能应对大多数光线环境，而它的色彩与宽容度又为创作提供了更多空间。未来的日常拍摄，我相信它还会继续陪伴我，把平凡的瞬间变成有质感的影像。

我的水杯

揭秘 ARP：IP 地址如何找到 MAC 地址

Fri, 13 Mar 2026 00:00:00 GMT

在计算机网络中，数据的传输遵循 OSI 七层模型，每一层都有其独特的职责与接口。当我们发送数据包时，位于第三层（网络层）的数据包携带了目标 IP 地址，但在传输到第二层（数据链路层）时，还需要添加目标节点的物理地址（MAC 地址）才能在局域网中正确传输。然而，网络层和链路层之间并没有直接关联，那么系统如何知道目标 IP 对应的 MAC 地址呢？这就是 ARP（Address Resolution Protocol，地址解析协议） 的用武之地。

什么是 ARP？#

ARP 是 TCP/IP 协议族中的一个关键协议，用于根据 IP 地址获取物理地址。通俗来说，当上层协议需要向某个 IP 发送数据包时，ARP 可以提供该节点对应的 MAC 地址，从而完成数据的帧封装与传输。

ARP 的工作原理#

情况一：主机在同一网段#

假设有两台主机 A 和 B 位于同一局域网内，ARP 的工作流程如下：

查找 ARP 缓存表 主机 A 首先检查本地 ARP 缓存表，看是否已经存在主机 B 的 MAC 地址。如果存在，则直接使用缓存的 MAC 地址封装数据帧，并发送给 B。
发送 ARP 请求 如果缓存中没有目标 MAC 地址，主机 A 会将数据报暂存，并以广播方式发送 ARP 请求。请求报文中包含主机 A 的 IP 和 MAC 地址，以及目标 IP（主机 B）的地址，目标 MAC 设置为全 0。
ARP 响应 网段内的所有主机都会接收到请求，但只有目标主机 B 会处理。当 B 检查到请求中的目标 IP 与自身 IP 匹配时，它会将主机 A 的 IP 和 MAC 存入自己的 ARP 表，并发送 ARP 响应报文（包含自身 MAC 地址）给 A。
更新缓存与发送数据 主机 A 收到响应后，将主机 B 的 MAC 地址加入 ARP 缓存，然后完成数据包的封装与发送。

情况二：主机不在同一网段#

当主机 A 与 B 不在同一网段时，ARP 仍然是数据包到达目标的关键：

主机 A 向本地网关发送 ARP 请求，请求目标 IP 为网关地址。
获得网关 MAC 地址后，A 将数据包封装并发送给网关。
如果网关未缓存主机 B 的 MAC 地址，它会广播 ARP 请求获取 B 的 MAC 地址；否则，直接将报文转发给 B。

通过这样的机制，无论主机是否在同一网段，ARP 都保证了 IP 到 MAC 的映射，从而实现局域网或跨网段的数据传输。

ARP 数据包结构#

ARP 报文包含一个关键字段 Opcode：

1 表示请求（Request）
2 表示应答（Reply）

这使得网络中的设备可以区分报文类型，确保正确响应或请求 MAC 地址。

ARP 看似简单，但它是局域网通信中不可或缺的基础组件。理解 ARP 的工作机制，有助于网络调试、故障排查以及网络安全防护。

从 0 开始：在阿里云 ECS 上部署 Astro 博客，并用 GitHub Actions 自动发布

Thu, 12 Mar 2026 00:00:00 GMT

最近把个人博客从本地开发环境迁移到了阿里云 ECS。服务器是全新实例，系统为 Ubuntu 24.04.4 LTS。这篇文章完整记录了从一台空白 ECS 开始，到博客可通过域名访问、启用 HTTPS，并且支持 GitHub Actions 自动部署的整个过程。

这篇文章适合以下场景：

你有一台全新的阿里云 ECS
你想部署的是 Astro 静态博客
你已经有自己的域名
你希望博客支持 HTTPS
你希望以后写完文章后，执行 git push 就能自动上线

本文最终实现的架构如下：

本地电脑负责写博客和提交代码
GitHub Actions 自动安装依赖、构建 Astro 项目
构建产物 dist/ 自动上传到 ECS
ECS 上的 Nginx 直接托管静态文件
域名解析到 ECS 公网 IP
网站通过 HTTPS 对外提供服务

一、为什么选择这种部署方式#

Astro 博客本质上非常适合静态部署。对于个人博客来说，没有必要在服务器上长期运行 Node 服务，更没必要把 ECS 当构建机。

更稳妥的做法是：

本地或 GitHub Actions 负责构建
服务器只负责托管静态文件
Nginx 负责访问入口和 HTTPS
GitHub Actions 负责自动发布

这种方式有几个明显优点：

第一，服务器压力小。第二，架构简单，出问题时容易排查。第三，CI/CD 清晰，后续维护成本很低。第四，适合 Astro、Vite 一类静态站点项目。

二、准备工作#

开始之前，需要准备好以下几样东西：

一台阿里云 ECS，系统为 Ubuntu 24.04
ECS 拥有公网 IP
一个已经注册好的域名
GitHub 仓库
本地已经有 Astro 项目，或者准备新建一个
一个可用的 SSL 证书（本文采用手动部署证书，而不是 Certbot）

如果你的 ECS 在中国大陆节点，网站正式上线前还需要关注备案要求。

三、服务器基础初始化#

先通过 SSH 登录 ECS。

Terminal window

1
ssh root@你的ECS公网IP

登录后先更新系统，并安装基础软件：

Terminal window

1
apt update && apt upgrade -y
2
apt install -y nginx git curl unzip ufw

如果你希望启用 Ubuntu 防火墙，可以继续执行：

Terminal window

1
ufw allow OpenSSH
2
ufw allow 80/tcp
3
ufw allow 443/tcp
4
ufw enable
5
ufw status

此外，在阿里云 ECS 控制台里，还需要确认安全组已开放以下端口：

22（SSH）
80（HTTP）
443（HTTPS）

如果安全组没有开放 80/443，即便 Nginx 配好了，外部也无法访问网站。

四、配置域名解析#

进入域名的 DNS 管理后台，添加两条 A 记录：

主域名解析：

记录类型：A
主机记录：@
记录值：ECS 公网 IP

www 子域名解析：

记录类型：A
主机记录：www
记录值：ECS 公网 IP

完成后可以在本地简单验证一下：

Terminal window

1
ping yourdomain.com
2
ping www.yourdomain.com

如果解析结果已经指向 ECS 公网 IP，就说明域名已经生效。

五、准备博客部署目录#

在服务器上创建博客目录：

Terminal window

1
mkdir -p /var/www/astro-blog
2
chown -R www-data:www-data /var/www/astro-blog
3
chmod -R 755 /var/www/astro-blog

为了便于确认 Nginx 配置是否成功，可以先放一个临时测试页面：

Terminal window

1
cat > /var/www/astro-blog/index.html <<'EOF'
2
<!doctype html>
3
<html>
4
  <head>
5
    <meta charset="utf-8">
6
    <title>Astro Blog Ready</title>
7
  </head>
8
  <body>
9
    <h1>Astro Blog 部署目录已就绪</h1>
10
  </body>
11
</html>
12
EOF

六、配置 Nginx 托管站点#

在 /etc/nginx/sites-available/ 下创建站点配置文件：

Terminal window显示更多显示更少

1
cat > /etc/nginx/sites-available/astro-blog <<'EOF'
2
server {
3
    listen 80;
4
    listen [::]:80;
5

6
    server_name yourdomain.com www.yourdomain.com;
7

8
    root /var/www/astro-blog;
9
    index index.html;
10

11
    location / {
12
        try_files $uri $uri/ /index.html;
13
    }
14
}
15
EOF

显示更多显示更少

启用站点，并关闭默认站点：

Terminal window

1
ln -s /etc/nginx/sites-available/astro-blog /etc/nginx/sites-enabled/astro-blog
2
rm -f /etc/nginx/sites-enabled/default
3
nginx -t
4
systemctl reload nginx

如果 nginx -t 输出 syntax is ok 和 test is successful，说明配置语法没有问题。

此时访问：

http://yourdomain.com
http://www.yourdomain.com

如果能看到测试页，说明：

域名解析正常
80 端口正常
Nginx 配置正常
站点目录可访问

七、创建或准备 Astro 项目#

如果你还没有 Astro 项目，可以在本地创建：

Terminal window

1
npm create astro@latest

如果你使用的是现成主题，比如 AstroPaper，也可以直接基于主题模板初始化。

进入项目目录后，安装依赖并本地运行：

Terminal window

1
npm install
2
npm run dev

本地确认页面正常后，执行生产构建：

Terminal window

1
npm run build

构建成功后，静态文件会输出到 dist/ 目录。

如果你的项目使用的是 pnpm，而不是 npm，那么命令应该改成：

Terminal window

1
pnpm install
2
pnpm build

八、Astro 项目的关键配置#

部署到正式域名后，建议确认 astro.config.mjs 或主题配置文件里已经写入正确的生产环境地址。

例如：

1
import { defineConfig } from 'astro/config';
2

3
export default defineConfig({
4
  site: 'https://yourdomain.com'
5
});

如果你使用 AstroPaper 之类的主题，还要修改主题自己的站点配置，例如：

网站标题
作者名
站点描述
正式域名
社交链接
时区
文章编辑地址

以 AstroPaper 为例，重点文件通常是：

src/config.ts
src/constants.ts

尤其要注意把正式域名填进去，否则 canonical URL、社交分享链接、SEO 信息可能都会不正确。

九、第一次手动部署 Astro 构建产物#

在启用自动化部署前，建议先手动部署一次，确保服务器侧配置没问题。

本地构建：

Terminal window

1
npm run build

或者：

Terminal window

1
pnpm build

然后通过 rsync 或 scp 把 dist/ 上传到 ECS。

例如：

Terminal window

1
rsync -avz --delete dist/ root@你的ECS公网IP:/var/www/astro-blog/

上传完成后，再次访问域名。如果已经能看到 Astro 首页，而不是之前的测试页，说明静态文件部署路径是正确的。

十、手动部署 SSL 证书#

本文使用的是手动申请的 SSL 证书，所以不使用 Certbot，而是手动把证书部署到 Nginx。

通常证书包里会有：

证书文件，例如 fullchain.pem 或 yourdomain.pem
私钥文件，例如 yourdomain.key

先在 ECS 上创建证书目录：

Terminal window

1
mkdir -p /etc/nginx/ssl
2
chmod 700 /etc/nginx/ssl

把证书文件上传到这个目录中，例如：

/etc/nginx/ssl/fullchain.pem
/etc/nginx/ssl/yourdomain.key

然后收紧权限：

Terminal window

1
chmod 600 /etc/nginx/ssl/yourdomain.key
2
chmod 644 /etc/nginx/ssl/fullchain.pem

接着修改 Nginx 配置，让 80 跳转到 443，并配置 HTTPS。

Terminal window显示更多显示更少

1
cat > /etc/nginx/sites-available/astro-blog <<'EOF'
2
server {
3
    listen 80;
4
    listen [::]:80;
5
    server_name yourdomain.com www.yourdomain.com;
6

7
    return 301 https://$host$request_uri;
8
}
9

10
server {
11
    listen 443 ssl;
12
    listen [::]:443 ssl;
13
    server_name yourdomain.com www.yourdomain.com;
14

15
    root /var/www/astro-blog;
16
    index index.html;
17

18
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
19
    ssl_certificate_key /etc/nginx/ssl/yourdomain.key;
20

21
    location / {
22
        try_files $uri $uri/ /index.html;
23
    }
24
}
25
EOF

显示更多显示更少

然后测试并重载 Nginx：

Terminal window

1
nginx -t
2
systemctl reload nginx

此时访问：

https://yourdomain.com
https://www.yourdomain.com

如果能正常打开，说明 HTTPS 部署完成。

十一、为 GitHub Actions 准备部署账号#

为了安全起见，不建议让 GitHub Actions 直接使用 root 用户登录 ECS。更合理的做法是创建一个专门的部署用户，比如 deploy。

Terminal window

1
adduser deploy
2
usermod -aG www-data deploy
3
mkdir -p /home/deploy/.ssh
4
chmod 700 /home/deploy/.ssh
5
chown -R deploy:deploy /home/deploy/.ssh

然后需要给这个用户配置 SSH 公钥登录。

十二、生成 GitHub Actions 专用 SSH 密钥#

在本地 Windows 电脑上，可以使用如下命令生成一对密钥。

Terminal window

1
mkdir %USERPROFILE%\.ssh
2
ssh-keygen -t ed25519 -C "github-actions-deploy" -f "%USERPROFILE%\.ssh\github_actions_astro"

会生成两个文件：

私钥：C:\Users\你的用户名\.ssh\github_actions_astro
公钥：C:\Users\你的用户名\.ssh\github_actions_astro.pub

查看公钥内容：

Terminal window

1
type %USERPROFILE%\.ssh\github_actions_astro.pub

会输出类似这样的一整行：

1
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... github-actions-deploy

把这一整行写入服务器上的：

Terminal window

1
/home/deploy/.ssh/authorized_keys

可以用 nano 打开：

Terminal window

1
nano /home/deploy/.ssh/authorized_keys

粘贴公钥后保存，再执行：

Terminal window

1
chmod 600 /home/deploy/.ssh/authorized_keys
2
chown deploy:deploy /home/deploy/.ssh/authorized_keys

一定要注意，authorized_keys 中写入的是：

github_actions_astro.pub 的内容

不是私钥文件内容。

另外，公钥开头必须是：

1
ssh-ed25519

如果写成了 sh-ed25519 之类的错误格式，SSH 会直接认证失败。

十三、先在本地测试 SSH 是否打通#

在正式跑 GitHub Actions 之前，建议本地先测试一次 SSH 登录。

Terminal window

1
ssh -i "%USERPROFILE%\.ssh\github_actions_astro" deploy@你的ECS公网IP

如果能成功登录，说明：

本地私钥没问题
服务器上的公钥没问题
用户名正确
权限正确

只有这一步先打通，GitHub Actions 的远程上传才有成功的基础。

十四、配置 GitHub 仓库 Secrets#

进入 GitHub 仓库：

Settings -> Secrets and variables -> Actions

添加以下几个 Secrets：

ECS_HOST：你的 ECS 公网 IP
ECS_PORT：22
ECS_USER：deploy
ECS_SSH_KEY：私钥文件 github_actions_astro 的完整内容

注意，ECS_SSH_KEY 填的是私钥全文，内容会包含：

1
-----BEGIN OPENSSH PRIVATE KEY-----
2
...
3
-----END OPENSSH PRIVATE KEY-----

不能把 .pub 文件内容填进这个 Secret。

十五、编写 GitHub Actions 自动部署 workflow#

如果你的 Astro 项目使用的是 pnpm，推荐使用下面这份 workflow。

创建文件：

1
.github/workflows/deploy.yml

内容如下：

1
name: Deploy Astro to ECS
2

3
on:
4
  push:
5
    branches:
6
      - main
7

8
env:
9
  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
10

11
jobs:
12
  build-and-deploy:
13
    runs-on: ubuntu-latest
14

15
    steps:
16
      - name: Checkout
17
        uses: actions/checkout@v5
18

19
      - name: Setup pnpm
20
        uses: pnpm/action-setup@v4
21
        with:
22
          version: 9.14.4
23

24
      - name: Setup Node
25
        uses: actions/setup-node@v5
26
        with:
27
          node-version: 22
28
          cache: pnpm
29

30
      - name: Install dependencies
31
        run: pnpm install --frozen-lockfile
32

33
      - name: Build Astro
34
        run: pnpm build
35

36
      - name: Upload dist to ECS
37
        uses: appleboy/scp-action@v1
38
        with:
39
          host: ${{ secrets.ECS_HOST }}
40
          username: ${{ secrets.ECS_USER }}
41
          key: ${{ secrets.ECS_SSH_KEY }}
42
          port: ${{ secrets.ECS_PORT }}
43
          source: "dist/*"
44
          target: /var/www/astro-blog
45
          strip_components: 1
46
          overwrite: true
47

48
      - name: Fix permissions
49
        uses: appleboy/ssh-action@v1
50
        with:
51
          host: ${{ secrets.ECS_HOST }}
52
          username: ${{ secrets.ECS_USER }}
53
          key: ${{ secrets.ECS_SSH_KEY }}
54
          port: ${{ secrets.ECS_PORT }}
55
          script: |
56
            chown -R deploy:www-data /var/www/astro-blog
57
            find /var/www/astro-blog -type d -exec chmod 775 {} \;
58
            find /var/www/astro-blog -type f -exec chmod 664 {} \;

显示更多显示更少

如果你项目使用的是 npm，就把 pnpm 相关命令替换成 npm 即可。

十六、pnpm 项目常见问题#

如果你使用的是 pnpm 项目，仓库根目录里必须提交：

1
pnpm-lock.yaml

否则 GitHub Actions 安装依赖时会失败。

另外，如果 package.json 中写了：

1
"packageManager": "pnpm@9.14.4"

那么 pnpm/action-setup 里也要保持同样版本，不能写成 10，否则会报版本冲突错误。

换句话说，workflow 里的 pnpm 版本必须和项目自己声明的版本一致。

十七、触发自动部署#

把 workflow 提交到仓库后，执行：

Terminal window

1
git add .
2
git commit -m "add deploy workflow"
3
git push

之后进入 GitHub 仓库的 Actions 页面，就能看到自动部署任务开始执行。

成功后，流程会是：

拉取仓库代码
安装 Node 和 pnpm
安装依赖
构建 Astro
把 dist/ 上传到 ECS
修复目录权限
网站自动更新

以后每次写完文章，只需要：

Terminal window

1
git add .
2
git commit -m "publish new post"
3
git push

新的内容就会自动部署上线。

十八、常见问题排查#

整个部署过程中，最容易踩到的坑主要有以下几类。

1. GitHub Actions 无法通过 SSH 认证#

典型报错是：

1
ssh: unable to authenticate, attempted methods [none publickey]

这通常说明：

ECS_SSH_KEY 不是正确私钥
服务器上的 authorized_keys 没写对
公钥格式写错
用户名不匹配
.ssh 或 authorized_keys 权限不正确

正确的排查顺序应该是：

先本地测试：

Terminal window

1
ssh -i "%USERPROFILE%\.ssh\github_actions_astro" deploy@你的ECS公网IP

只有本地这条能通，GitHub Actions 才有机会成功。

2. `authorized_keys` 公钥格式错误#

这是一个很隐蔽但常见的问题。比如原本应当是：

1
ssh-ed25519 AAAA...

如果误写成：

1
sh-ed25519 AAAA...

那么 SSH 会直接把这行视为无效公钥，导致始终认证失败。

3. pnpm 版本冲突#

如果 workflow 里写的是：

1
version: 10

但 package.json 里写的是：

1
"packageManager": "pnpm@9.14.4"

则会报多版本冲突错误。

解决方法很简单：保持两边完全一致。

4. 找不到 lock file#

如果项目是 pnpm 项目，却使用了 npm 的 workflow，可能会报找不到 package-lock.json。

解决思路是：

使用 cache: pnpm
使用 pnpm install --frozen-lockfile
确保仓库里有 pnpm-lock.yaml

5. HTTPS 配好了但站点打不开#

这种情况优先检查：

阿里云安全组是否放行 443
UFW 是否放行 443
证书路径是否写对
证书和私钥是否配对
Nginx 是否重载成功

十九、最终效果#

完成上述所有步骤后，你会得到一个完整可用的个人博客部署方案：

域名已经绑定到阿里云 ECS
Nginx 正常提供静态站点
网站通过 HTTPS 对外访问
每次提交代码后，GitHub Actions 自动构建并部署

这个方案对个人博客来说已经足够稳定，而且维护起来非常轻松。

二十、结语#

这次部署最大的感受是：对于 Astro 这类静态站点，最省心的方式并不是在服务器上运行开发环境，而是把服务器当作一个稳定的静态资源托管端。

本地负责开发。 GitHub Actions 负责构建。 ECS 负责托管。 Nginx 负责访问和 HTTPS。

职责清晰，问题也更容易定位。

如果你也正好在用阿里云 ECS、Ubuntu 24.04、Astro 或 AstroPaper，希望这篇记录能帮你少踩一些坑。

DaydreamNation

本科回忆录 1

本科回忆录 1#

Git 忽略规则踩坑：为什么 .gitignore 有时候完全没用？

Git 忽略规则踩坑：为什么 .gitignore 有时候完全没用？#

🧨 问题复现#

❗核心误区#

实际规则是：#

🧠 Git 的真实逻辑#

🔍 两种常见情况对比#

情况 1：你只是删除了文件 ❌#

情况 2：你取消了跟踪 ✅（正确做法）#

🚀 一步到位的修复方案（推荐）#

这一步做了什么？#

🧪 自检方法（强烈建议）#

正常情况：#

异常情况：#

⚠️ 一个非常容易忽略的坑#

🧹 如果你想连历史一起清掉（进阶）#

📌 最终总结#

🧩 一句话理解本质#

✍️ 后记#

大连周末散心：喝喝

大连周末散心：喝喝#

EXIT#

#4#

#6#

Gimlet#

Bamboo#

Tidal#

Twentieth Century#

White Gimlet#

总结#

大连周末散心：吃吃

大连周末散心：吃吃#

拉面：面道场#

烧鸟：烧鸟屋#

海鲜饭：人生渔鲜饭#

Gimlet 的新尝试：薄荷金酒与利10号的对话

Gimlet 的新尝试：薄荷金酒与利10号的对话#

配方概览#

调制步骤#

风味思考#

总结#

浅谈柯达电影卷5219：一款“全能”的胶卷

浅谈柯达电影卷5219：一款“全能”的胶卷#

揭秘 ARP：IP 地址如何找到 MAC 地址

什么是 ARP？#

ARP 的工作原理#

情况一：主机在同一网段#

情况二：主机不在同一网段#

ARP 数据包结构#

从 0 开始：在阿里云 ECS 上部署 Astro 博客，并用 GitHub Actions 自动发布

一、为什么选择这种部署方式#

二、准备工作#

三、服务器基础初始化#

四、配置域名解析#

五、准备博客部署目录#

六、配置 Nginx 托管站点#

七、创建或准备 Astro 项目#

八、Astro 项目的关键配置#

九、第一次手动部署 Astro 构建产物#

十、手动部署 SSL 证书#

十一、为 GitHub Actions 准备部署账号#

十二、生成 GitHub Actions 专用 SSH 密钥#

十三、先在本地测试 SSH 是否打通#

十四、配置 GitHub 仓库 Secrets#

十五、编写 GitHub Actions 自动部署 workflow#

十六、pnpm 项目常见问题#

十七、触发自动部署#

十八、常见问题排查#

1. GitHub Actions 无法通过 SSH 认证#

2. authorized_keys 公钥格式错误#

3. pnpm 版本冲突#

4. 找不到 lock file#

5. HTTPS 配好了但站点打不开#

十九、最终效果#

二十、结语#

2. `authorized_keys` 公钥格式错误#