企业官网建设流程全解析

很多朋友第一次用 Codex 写完个人网站，都会经历一个非常相似的场景：本地浏览器里一切正常，页面布局、配色、交互都没问题，但当你把地址发给别人时，对方却打不开。你每次想改几个字，都要重新打包、重新传文件、再清缓存，反复几次之后，连更新网站的动力都没了。

这篇文章要解决的就是这两个具体问题：让网站能被公网访问，并且让每次迭代不再手动上传。我会用 Codex + GitHub Pages 这个组合，把“本地写代码”和“云端自动发布”串成一条流水线。先说结论：Codex 负责写代码、改代码，GitHub Pages 负责托管和自动发布，两者配合之后，你的个人网站就变成了“本地改代码 -> Git 提交 -> 云端自动部署 -> 公网更新”的自动化链路。

1. 先搞清楚：为什么本地能跑，别人却访问不了？

很多人第一次把网站给别人看时，都会说“你打开 http://localhost:8000 看看”。这句话的本质问题，是把“本地预览”和“公网访问”混成了一件事。要理解部署流程，先得把这两者的区别讲清楚。

1.1 本地预览和公网访问是两套逻辑

你用 Codex 生成一个网页后，在本机浏览器打开 localhost，页面能显示，这只是说明代码在你这台电脑上运行正常。localhost 这个地址永远指向“当前这台电脑”，不会指向任何人的电脑。你把这个地址发给朋友，对方打开后，浏览器访问的是他本机的 8000 端口，自然不可能看到你的页面。

如果你的电脑和对方在同一个局域网内，你把地址换成局域网 IP，对方也许能打开。可一旦离开同一个网络，这个地址又会失效。因为你的电脑没有公网 IP，也没有一个稳定的公网入口。这里的关键不是代码写得不好，而是访问路径根本没有到达公网。

想让网站被所有人访问，本质上是把静态文件放到一台有公网域名的服务器上，通过 HTTP 协议对外提供访问。你的电脑当然也可以充当服务器，但这需要公网 IP、端口映射、持续开机，还要处理安全防护和带宽限制，对个人网站的维护成本来说很不划算。GitHub Pages 把这一步变成了非常轻量的操作：你只需要把文件推送到 GitHub 仓库，平台会自动帮你托管和发布。

1.2 这个方案适合什么网站，不适合什么网站

GitHub Pages 适合部署静态网站，也就是纯 HTML、CSS、JavaScript，不依赖后端运行时的内容。如果你用 Codex 生成的是个人主页、作品集、简历页、项目文档站、工具页，那这些大多属于静态内容，很适合用这个方案。如果网站里包含用户登录、数据库存储、实时聊天、支付回调等动态功能，那至少需要额外的后端服务，不能只靠 GitHub Pages 完成。

这不是工具本身的缺陷，而是职责边界。很多人一上来就想着把整个应用塞进 GitHub Pages，遇到问题后反过来怀疑方案不行。正确做法是先在“静态个人网站”这个范围内使用它，等你需要动态功能时，再考虑把后端拆到其他服务里，前端仍然可以用 GitHub Pages 托管。

1.3 真正的坑不是“不能访问”，而是“没有发布流程”

如果你只是想让网站临时给别人看一眼，方法其实很多，比如临时起一个本机服务、用一些在线编辑器预览，但这些方案都不适合长期维护。临时方案往往只能解决一次性的展示需求，解决不了“后续每次更新都要重复劳动”的问题。

手动上传是很多人在个人网站上最早的发布方式：打开上传工具，选择文件，覆盖到服务器，再清一下缓存。第一次可能还能接受，但修改次数多了就会发现，所有时间都耗在重复动作上。更麻烦的是，手动上传经常会漏文件、传错目录，本地文件和线上文件不一致，最后你也不知道线上到底跑的是哪一版代码。

所以，解决这个问题的关键不是找到一个“能免费放网页的地方”，而是把发布动作固化成一条自动流程。一旦流程跑通，你的每次修改都通过 Git 提交触发云端自动部署，不再需要手动干预。

2. 为什么选择 Codex + GitHub Pages？它解决的到底是什么问题？

这个组合看起来简单，但它真正解决的不是“省几分钟上传时间”，而是把个人网站开发中最容易忽略的“发布一致性”变成了一件确定的事。

2.1 Codex 真正的价值，是能直接参与项目而不是只给建议

在常见用法里，Codex 不是只给你一段代码然后让你自己粘到项目里，它能够读取项目目录、修改现有文件、执行命令，甚至根据报错信息做二次修复。这意味着它可以参与“写-改-查-修”的完整循环。你给它一个提示，它生成页面；你发现标题不居中，它去改样式；本地起服务报错，它可以查看日志并尝试修复。

对使用者来说，最重要的体验是：Codex 能感知当前项目状态。你不需要每轮都重新描述整个网站结构，只需要告诉它“在现有页面里加一个联系方式区块”，它会在合适的位置插入结构，并尽量沿用已有的样式风格。这种工作方式可以让迭代变得非常快，但前提是你得有稳定的流程来承接每次改动，否则只是“生成代码更快”，网站上线的问题依然没有解决。

这里有一点要提醒：Codex 生成的代码，仍然需要你验收。它更像一个动手能力很强的协作者，而不是一个全自动的文件生成器。你要做的是本地预览、提交、验证线上结果，形成闭环。

2.2 GitHub Pages 的底线和上限

GitHub Pages 的底线是免费、稳定、支持 HTTPS，个人网站放上去之后你不需要管服务器。它不会像自己的云服务器那样，突然因为系统更新、进程挂掉、证书过期而出现访问问题。把静态文件交给它托管，可以让个人网站长期稳定运行。

它的上限也很清楚：主要托管静态文件，没有完整的后端运行环境。对于一个个人主页或者项目文档站，这完全够用；但如果你的网站需要动态计算、数据库、服务端接口，那就必须引入其他服务。很多初学者的误区是希望 GitHub Pages 能做所有事情，最后发现做不到，就觉得方案不好。其实正确的判断标准应该是：先明确你的网站是否需要后端，再选择托管方式。

2.3 和手动上传相比，真正变化的是什么

这个表格里最核心的一行是“部署一致性”。手动上传最大的问题，不是慢，而是你不确定线上文件是否和本地完全一致。Git 的方式把“线上状态”变成了“某个 commit 的产物”，这是确定性的来源。只要线上有问题，你可以回到任意一个已知稳定的提交，重新发布，不用从头排查到底是哪个文件传错了。

3. 新手最容易卡住的四步：从 Codex 到 GitHub Pages 的最小可用流程

下面这套流程以最简单的静态个人主页为例，不涉及复杂框架，目的是让读者先跑通一次完整链路。只要这条链路通了，后面所有迭代都会变得很轻松。

3.1 准备：创建一个空仓库和一个本地项目目录

第一步，去 GitHub 注册账号并登录，创建一个公开仓库。仓库名有两种选择：如果你想访问地址最直观，可以命名为你的用户名.github.io，比如zhangsan.github.io。如果不用这个命名，也可以创建普通仓库，但访问地址会变成你的用户名.github.io/仓库名。

第二步，在本地新建一个项目目录，并初始化 Git：

mkdir my-site cd my-site git init

第三步，在 Codex 中打开这个目录，给它一个清晰的初始任务。这里有一个很重要的原则：先让 Codex 在一个空白目录里生成一个最小页面，而不是在一个复杂项目里叠加需求。最小页面能最快暴露链路问题，比如 Git 是否认出了目录、Codex 是否写入了文件、仓库结构是否正常。

3.2 用 Codex 生成页面，并在本地验证

在 Codex 里可以这样描述任务：

“请在这个目录里创建一个个人主页，使用单个 HTML 文件，包含标题、简短的自我介绍、项目展示区和一个联系方式链接。样式简洁，移动端友好，不需要外部图片。”

如果是验证流程，单个 HTML 文件已经足够。Codex 通常会生成一个index.html写到项目根目录。如果你的本地环境没有安装 Codex，手写一个极简 HTML 也可以跑通流程，重点是理解从本地到线上的完整链路。

生成本地文件后，先在本地验证代码本身是否正常。可以用 Python 自带一个静态服务器：

python3 -m http.server 8000

然后浏览器打开http://localhost:8000，确认页面能正常显示。这一步的实际价值，是把“代码写错”和“部署出问题”分开。如果本地都打不开，先别急着推送，更不要直接去 GitHub Pages 排查。

3.3 第一次推送，并开启 GitHub Pages

本地文件确认没问题后，就可以提交并推送到远程仓库。以 main 分支为例，常见命令如下：

git add . git commit -m "feat: 初始化个人主页" git branch -M main git remote add origin https://github.com/yourname/yourname.github.io.git git push -u origin main

如果你的仓库已经关联过远程地址，就跳过git remote add，用git remote set-url origin ...来修正地址。

推送完成后，进入 GitHub 仓库页面，找到Settings -> Pages，在 Source 选项里选择Deploy from a branch，分支选main，目录选root，保存。等待一两分钟，访问https://yourname.github.io/，应该能看到你的页面。如果仓库名不是你的用户名.github.io，访问地址会变成https://yourname.github.io/仓库名/，这个路径会直接影响后面资源文件的引用方式。

3.4 验证自动部署：改一行字，再看页面

现在做一次最小迭代，改一下index.html里的标题文字，比如把 “My Website” 改成 “我的个人主页”。然后执行：

git add . git commit -m "feat: 更新标题" git push

等待一两分钟，再次访问公网地址。如果标题变了，说明自动部署链路已经打通。如果没变，不要马上重复推送，先进入下一步排查。

这一步特别重要。很多人在第一次部署成功后，会让 Codex 一次性生成几十个页面，然后 push 上去，结果线上出了问题很难定位。更稳的做法是先验证最小闭环，再逐步扩展。流程跑通之后，你后续的每次改动都可以按照同样方式提交，网站会自动更新。

注意：GitHub Pages 的构建不是即时完成的，通常需要一分钟到几分钟。看到线上没变时，先刷新并等待，不要反复 push 制造无意义的提交记录。

4. 为什么 push 之后不用再手动上传？理解自动部署的底层链路

当你第一次跑通“push 后页面自动更新”时，会觉得很神奇。其实背后并没有魔法，只是一套非常清晰的触发机制。

4.1 push 之后到底发生了什么

当你执行git push时，本地的提交会被传送到 GitHub 远程仓库。GitHub Pages 在后台监听你指定的分支和目录，一旦检测到新的 commit，就会触发一次发布流程：读取仓库内容，把设定目录作为网站根目录，然后将静态文件发布到 GitHub 的托管节点，通过公网提供给访问者。整个过程里，你没有登录服务器、没有复制文件、没有修改 Nginx 配置，这些动作都由平台完成。

如果你选择的是 GitHub Actions 方式，流程会更明确：push 会触发一个 workflow，比如执行构建脚本、生成静态文件，然后把产物发布到 Pages。你可以在仓库的 Actions 页签里看到每次提交对应的任务日志。如果你用的是 branch 模式，就没有完整的构建日志，静态文件会直接发布，适合最简单的纯静态页面。

4.2 为什么 git push 比手动上传更接近“正确做法”

手动上传的隐患，是线上文件变成了一个没有版本关系的“复制品”。你很容易出现这种情况：本地改了三处，上传时只覆盖了两个文件，第三个忘了；或者本地目录结构和线上不一致，导致样式、图片全部路径错乱。这种问题一旦发生，你只能靠记忆去猜哪个文件不对，非常消耗耐心。

Git 方式的核心价值，是让“线上状态”和“某个提交”产生强绑定。你不需要记住这次改了哪些文件，因为 commit 已经记录了完整快照。线上如果出问题，你可以回到上一个提交，重新发布一个已知稳定的版本。这比任何手动备份都可靠。

4.3 常见失败场景和排查顺序

页面部署失败，通常集中在几类问题。排查时不要一上来就怀疑 GitHub Pages 服务有问题，而是要按顺序观察。

• 页面完全不显示，出现 404：先看仓库根目录有没有index.html；再看 Pages 设置里的分支和目录是否正确。
• 页面能打开但样式崩了：检查 HTML 中 CSS 的引用路径。如果你的仓库名不是你的用户名.github.io，访问地址会带一个二级路径，此时 CSS 如果写成了/style.css，浏览器会去域名根目录找文件，自然找不到。解决办法是用相对路径style.css，或者在框架中正确配置 base URL。
• 页面显示的还是旧版本：先强制刷新，再等几分钟，最后看最后一次 commit 时间是不是真的发上去了。
• 使用 Actions 时构建失败：进入 Actions 页签，找到最新的 workflow run，点开查看具体步骤日志。构建失败通常会在日志里给出明确原因，比如依赖安装失败、命令不存在、产物目录不对。

排查顺序也可以固定成一条链路：先看现象，再看输入，再看日志，最后再调配置。很多人遇到问题时，第一反应是去改 Pages 设置，其实大多数情况是文件路径或目录结构出了问题。

5. 把“Codex + GitHub Pages”沉淀成一个可复用流程

到这里，单次部署你已经会了。但真正让这套方案产生长期价值的，是把过程沉淀成一套可以稳定复用的工作流。

5.1 三阶段工作流

第一阶段是最小闭环。目标只有一个：让你的公网地址能打开一个index.html。不要在这个阶段追求页面美观、内容丰富，也不要急着让 Codex 一次生成十个页面。最小闭环的价值是确认整条链路没有断裂。

第二阶段是持续迭代。每次只给 Codex 提一个小需求，比如“把标题改成中文”“新增一个作品卡片”。Codex 修改后，你在本地预览，确认没问题再提交推送。推送后到线上验证一次。这个阶段要养成习惯：每次迭代的改动范围尽量小，commit 信息尽量清楚，比如feat: 新增项目展示区、fix: 修正移动端导航样式。这样回滚时能快速定位“哪一次改动引入了问题”。

第三阶段是工程化增强。当你觉得纯 HTML 页面已经不够用，可以引入静态站点生成器，比如 Astro、Vite、Jekyll 等，让 Codex 参与构建配置，再用 GitHub Actions 做自动构建和发布。也可以绑定自定义域名、配置 HTTPS、增加一个简单的资源压缩步骤。但要注意，这个阶段不要提前到来。如果你的网站只是个人主页，盲目引入复杂构建流程，反而会让每次更新变得沉重。

5.2 每一次迭代的检查和提交规范

下面这个检查清单，是每次推送前都可以快速过一遍的：

• 本地预览过吗？页面是否能正常打开？
• 是否只改动了本次需求相关的文件？
• git add是否带入了不必要的临时文件？
• commit 信息是否清晰，比如feat、fix、style前缀？
• push 后是否在线上验证过结果？

这个清单看起来很基础，但能解决绝大多数“部署后出现问题”的情况。很多线上问题不是部署系统坏了，而是提交前没有检查清楚。

5.3 适用边界：哪些场景别用这个组合

适合使用 Codex + GitHub Pages 的场景包括：

• 个人主页、作品集、简历页
• 技术文档、静态博客
• 开源项目展示页
• 纯前端的活动页、工具页

不适合的场景包括：

• 需要服务端 API、数据库、用户登录的完整应用
• 需要持续运行后台任务的网站
• 对低延迟和高可用要求非常高的大型站点
• 需要私有访问的内容

需要特别提醒的是，GitHub Pages 的公开仓库默认是公开的，网站内容也会公开。如果有些内容不想公开，不要放到这个方案里。边界划分清楚，后续使用才会顺畅。

还有一个容易被忽略的点：如果你计划长期使用 GitHub Pages，建议把域名绑定和 HTTPS 配置也纳入计划，但它不是第一优先级。先把页面跑通，再谈域名和优化。

6. 最后说句实在话：先跑通最小流程，比任何技巧都重要

Codex 和 GitHub Pages 都不是神奇的按钮。Codex 让你写网站更快，GitHub Pages 让你发布更稳定，但真正让这件事长期成立的，是你亲手跑通的那条最小流程。一次成功的push -> 自动更新体验，比看十篇教程都有用。

下一步可以先从一个很小的动作开始：新建一个目录，让 Codex 生成一个只有标题的页面，推到 GitHub，开启 Pages，改一行文字，再推送一次。等到页面自动更新，你的个人网站工作流就已经成立了。之后你真正需要投入精力的地方，是内容、设计，以及你网站想表达的东西，而不是反复处理和上传文件这类没有积累的事。