basil/personal-homepage 开发日志
这次的改动量不小，连着推了 3 个 commit，加加减减一共 401 行新增、81 行删除，主要集中在分享卡片、项目卡片的视觉调整，以及部署脚本的功能拆分上。目标就一个：让页面读起来更舒服，同时不让样式微调每次都拖一次全量发布。
分享卡片：从多列网格退回到单列列表
在 shares.astro 里，我把原来的 card-grid 布局整个换成了 shares-list，移除了 <article class="card"> 的包裹，用一套简单的单列网格承接内容。
之前那个网格排列实在太挤了，视觉密度高得让人不太想细看。一眼扫过去所有条目糊在一起，反而丢了“分享”该有的呼吸感。改成单列列表之后，观感和 logs 页面保持一致，阅读顺序更自然，每一条链接都有独立的纵向空间，不再是一大坨信息集中轰炸的压抑感。可以说，这是有意识地牺牲了一点信息密度，去换一种更松弛、更易决策的浏览体验。当时也想过用紧凑型卡片或者可展开摘要，但两种方案都会引入新的交互复杂度，最终还是觉得老老实实走单列最省心。
项目卡片：在密集三列网格里重建扫描节奏
ProjectCard.astro 这边的改动有两个层面：组件内部的排版，以及列表层的排序规则。
组件层面，我重新组织了卡片的内部结构，改用 CSS Grid 来控制间距和区块关系（display: grid; gap: 1rem），同时把 source 重命名成了 _source，避免跟未来可能的外部变量名冲突。顺手清掉了未使用的 formatDateTime 导入，保持依赖干净。
列表层面，在 projects/index.astro 中加上了按 featured 字段的排序逻辑。目前是两级排序：第一级看是否精选，精选项目置顶；第二级直接按更新时间降序，保证同一级内部也有稳定的展示顺序。这比纯自然顺序要合理得多，至少搜索结果有了一个默认的优先级表达，而不是随机排列。后续如果维护得勤，再考虑加入重要性权重或者置顶过期机制也不迟。
部署流程：dev-deploy 与 full-deploy 拆分
这是本次最“工程化”的一个改动。之前每次改点样式、调个文案，都要跑一遍完整的部署流程，连资源同步也跟着折腾一遍，发布负担不小。于是我在 scripts/deploy-homepage.sh 里拆出了两种模式：带资源同步的全量部署（full-deploy），和不带资源同步的开发部署（dev-deploy）。
实现上引入了两个环境变量来切分行为：RUN_LOG_SYNC 控制是否执行资源同步，DOCKER_FORCE_BUILD 控制 Docker 镜像是否每次都强制重建。脚本里也补上了 usage() 帮助信息，免得自己以后忘掉这些变量的作用。目前的默认值是 RUN_LOG_SYNC=true 且 DOCKER_FORCE_BUILD=true——也就是说，如果不带参数跑，它还是会走全量路径，安全偏向完整。CI 流水线里用的自然也是 full-deploy，确保自动化环境始终拿到完整构建。而日常改 CSS 这种场景，就可以手动指定走 dev-deploy，快速验证，省下不少等待时间。
连带这次还顺手修了两个数据示例文件里的错误：seafile/index.json 中的项目仓库路径从 basil/personal-homepage 改成 basil/biography-of-lijie，分享条目名称也从旧的需求文档描述更新成了“配置样例结构”，首页上那处可怜的提示文案也从 502 改成了 404——终于说人话了。
后续需要盯一下的
- 分享列表的密度调整在宽屏上效果可以，但在移动端需要看看是不是过于稀疏；如果单屏展示条目太少，可能还得补一套紧凑模式。
featured排序依赖内容维护，如果 CMS 里这个字段没人持续打理，精选的权重就形同虚设，届时得考虑自动衰减或者补一个后备排序。- 部署脚本的环境变量默认值虽然目前够用，但缺少文档说明是个隐患，至少得在项目 README 里把 dev/full 的使用方式写清楚。
- 数据文件的修改仅限于开发环境示例，需要确保不会意外影响到线上内容源。
注：本文由模型
deepseek-v4-pro生成（草稿与终稿同模型）。