DEVELOPMENT JOURNAL / 开发手记
页面应该承担什么任务？截图如何保持比例？切换主题时，正在编辑的内容怎么办？把本项目对话中的具体要求，与开发、测试和发布记录放在一起，整理成八篇可以回看的笔记。
阅读学习笔记01 / 学习笔记
整理于 2026.09.26
来自本项目需求讨论及已有开发记录。
文中的引文来自本项目对话，技术结果依据对应日期的开发与验收记录。没有明确日期的对话不补写发生时间；历史测试结果仅说明当次验证范围。
“我要的是一个介绍的静态网站”
网站需求讨论中，这句话明确了交付对象：一个独立的介绍页面。围绕它展开的工作包括信息顺序、手机阅读、图片比例、页面底部信息，以及静态资源的发布。页面自身需要有完整的阅读路径，访问者进入后便能理解内容，继续查看相关说明。
项目把网站放在独立目录，并使用单独的 Vite 配置和构建目录。页面修改、静态构建与服务器发布因此可以分别检查。修改介绍内容时，核对文件变更范围和受保护代码的文件摘要，可以确认其他客户端与后端是否保持原样。
一项页面任务应同时说明读者、内容和发布对象。名称相同的项目可能包含多个客户端、网页和接口，完成其中一部分需要相应的证据。现在这份网站承担个人开发记录的阅读用途，保留完整文字、目录和网站说明，让内容本身可以独立成立。
整理依据：本项目网站需求对话；2026-09-16、2026-09-26 网站发布记录。
“手机端截图千万不能拉长压缩了，按照常规iphone比例截图”
这项要求给图片展示增加了明确约束：页面里的手机画面必须保持原始长宽关系。项目的一次发布记录采用了 390 × 844 的视口，导出的图片尺寸为 367 × 794。两组数据分别描述采集视口和图片文件，使用时需要分别核对。
处理这一类素材时，图片宽度可以随父容器调整，高度按照原始比例计算。需要完整展示时，容器采用对应的 aspect-ratio，图片使用 object-fit: contain。手机外框、装饰背景和说明文字保持独立，不能通过改变图片高度补齐版面。
2026-09-16 的记录同时核验了文件尺寸和浏览器加载后的展示：七张画面以 367 × 794 加载，检查覆盖桌面与手机宽度，并记录横向溢出和请求状态。这个案例提醒我，文件正确、样式正确和最终显示正确，是三个需要分别确认的环节。
整理依据：本项目截图比例相关对话；2026-09-16 网站发布记录。本文讨论图片处理方法，当前页面不加载这些历史图片。
“适配手机端”
对话随后继续提出了页面某个区域过高、说明与对应图片相距过远的问题。这补充了手机适配的另一层含义：同一组内容应当容易一起理解，读者不需要经过大幅滚动才能找到说明所对应的对象。
电脑上的并列区域可以在手机上改为纵向排列，但标题、说明和对应内容仍然属于同一组。固定高度应有明确用途，纯粹用来撑开版面的高度可以交由内容决定。导航需要允许换行，长标题和链接应能在可用宽度内排列，页面边距也要同时考虑阅读空间。
本站在 2026-09-26 的验收覆盖 320、390、768 和 1440 像素四种宽度。检查包括文档宽度是否超出视口、导航能否到达正文、备案链接是否完整显示，以及禁用 JavaScript 后能否继续阅读。这些结果说明了对应尺寸下的浏览器表现，物理设备上的触控感受仍然需要单独检查。
整理依据：本项目手机适配与区域间距相关对话；2026-09-26 网站 DOM 验收记录。
项目的原生界面记录把页面分为顶栏、独立画布区和底部操作区。进入编辑状态后，预览区域与表单分别占据明确的空间，标题、取消按钮和应用按钮也有清楚的位置。尺寸变化需要传递到实际画布，保证渲染区域与页面布局同步。
命名、隐私说明等弹窗出现时，背景画布需要配合隐藏，相关手势反馈也随之停止。关闭弹窗后，画布和操作恢复到对应状态。首次进入页面又有不同要求：画布应先取得尺寸并完成初始化。这些时序需要由页面状态统一控制。
2026-09-14 的记录包含普通、编辑、全屏和公共弹窗等状态，共有 27 条原生界面检查记录，并完成 178 项自动测试。检查关注画布边界、按钮尺寸、弹窗恢复和长名称等情况。记录同时明确了范围：当时验证来自开发工具，真实手机上的键盘、触控和系统页面仍需设备验收。
整理依据：2026-09-14 原生界面调整交付记录。测试数量为当次记录，不能推导为所有设备均已通过。
项目的一次界面复查涉及下拉、关闭、保存等入口。后续记录采用本地 Lucide PNG 统一图标，并为菜单入口保留相同的图标区域。检查既关注图片尺寸，也关注图文中心、点击区域和文字起点；同一张图标在不同控件里仍需要结合布局确认。
主要按钮通过适当的明暗和边缘强调获得清楚的入口位置，普通操作采用较安静的表达。按下、禁用和当前状态需要各自可辨。用于背景的装饰保持静态，记录中明确说明没有增加动画循环，也没有更改既有业务逻辑。
当次记录列出了 26 个运行时 PNG 图标，缩略图合计 45,924 B，并通过项目包体检查。这里的字节数来自当时的交付记录。这个过程让我把素材维护理解为一项工程工作：尺寸、引用位置、许可证与包体成本，都应与界面效果一起确认。
整理依据：2026-09-15 界面复查报告与界面优化交付记录。资源数字仅对应当次版本。
项目的双主题开发记录除了颜色配置，还明确处理了一个具体流程：用户正在编辑内容，通过菜单进入设置切换主题，再返回继续编辑。这个过程中，尚未应用的草稿需要保留；取消和页面卸载仍然遵守各自的清理规则。
界面主题与业务配置分开保存，独立组件显式接收主题，原生状态栏和开关也一起更新。跨设置页面的草稿保留有明确入口，导航失败时清除相应标记。这样的安排让主题更新、页面生命周期和编辑内容各有明确的责任范围。
2026-09-15 的记录包含主题记忆、全屏切换、独立组件配色和跨设置页面保留草稿等 12 组原生回归，并记录了 185 项全项目测试通过。这项工作留下的经验是：视觉设置应当放进完整操作路径中检查，返回上一页之后，用户才能确认原来的工作是否仍然可继续。
整理依据：2026-09-15 双主题本地验收记录。当时的结果来自本地开发工具，设备表现单独验收。
2026-08-23 的一份运行记录分别检查了官方预览、页面路由、组件初始化和画布状态。编译通过能够说明代码生成过程完成，页面是否进入就绪状态、渲染器是否已经创建，则由运行时检查给出证据。
记录中的渲染实例使用 sceneRenderer 命名，使自定义实例与框架内部字段具有明确区别。启动过程分别处理页面首帧、场景挂载和后续计算，资源分包加载成功后再进入相应页面。这样的组织方式使初始化依赖能够被逐项检查。
记录中的验证既包括编译，也包括页面路由、ready 状态、画布和渲染器是否存在。冷启动从明确入口开始，连续操作再检查页面切换与资源就绪。两个入口可能具有不同的已有状态，因此都需要留下独立结果，才能说明页面启动过程已经得到验证。
整理依据：2026-08-23 构建与布局验证报告。本文保留初始化方法和验证范围，不展示历史运行画面。
项目的静态发布记录为每次发布保留编号、源码版本、构建包摘要和部署结果。HTML 与样式经过构建后组成发布包，上传后再次核对 SHA-256。线上首页也与本地构建比较摘要，这样可以确认访问者收到的文件与待发布版本相对应。
静态网页与后端接口由不同路径处理。网站发布只替换对应的静态目录，保留前一版本作为恢复依据。发布前后检查 API 的服务身份和健康状态，判断依据采用稳定字段；包含时间的响应会自然变化，需要按照字段含义检查。
2026-09-26 的网站记录包含 26 项自动测试，以及主域名和 www 域名各四种屏幕宽度的浏览器检查。检查覆盖正文、目录链接、CSS 资源、页脚备案链接及禁用 JavaScript 后的阅读。浏览器访问通过、手机设备验收和备案审核各有独立证据，本次笔记保留这几个结论之间的边界。
整理依据：2026-08-29、2026-09-16、2026-09-26 网站发布记录。公开内容不包含服务器地址、账号或内部操作路径。
02 / 创作记录
整理日期与事件日期分别标注，历史数据保留原有验证范围。
本次从网站需求讨论中提取页面定位、截图比例、手机适配三组问题，再结合已有交付记录，补充界面结构、资源管理、主题状态、运行验证与发布方法。
每篇笔记保留来源说明。引文沿用对话原文，日期来自已有记录，验证数字只在其原有范围内使用。全部正文直接展示，通过目录可以到达对应文章。
返回笔记目录03 / 关于本站
本站由个人维护，用于整理本项目开发过程中的需求讨论、界面设计思考、工程方法与验收记录。内容按主题重新编排，供访问者阅读参考。
这里记录已经有资料支持的事情，也说明尚未验证的范围。感谢你的阅读，愿这些具体的过程能为下一次制作提供参考。