普通视图

昨天以前icy's blog

从 CallBack 到 Promise，React 框架异步开发学习心得

作者 icy

2023年2月4日 22:00

<h2 id="引入"><a href="#引入" class="headerlink" title="引入"></a>引入</h2>说起 React，我印象最深刻的是，在 React 中，数据是<a href="https://zh-hans.reactjs.org/docs/state-and-lifecycle.html#the-data-flows-down">向下流动</a>的（<a href="https://www.php.cn/website-design-ask-493282.html">react 为什么是单向数据流</a>）——越高层级的组件，获得着越多的数据，而低层级组件数据的获取和更新，大多都通过<a href="https://zh-hans.reactjs.org/docs/components-and-props.html">组件属性传递</a>以及<a href="https://juejin.cn/post/7065555069889937415">回调函数</a>方式得到。这就意味着，高层组件刷新会同时刷新低层组件，而低层组件刷新往往不会带动高层组件刷新，于是更多的状态和逻辑会出现在比较高层级的组件里，在 React 中叫做<a href="https://zh-hans.reactjs.org/docs/lifting-state-up.html">状态提升</a> 。例如对话框的打开与关闭更应该是对话框组件的属性，而不是对话框组件的状态——对话框的操作往往与高层数据相关，如果把状态放在低层级，则很难把当前的状态和数据与高层级组件交互。在这种数据流的模式下，为了使得基本组件“动起来”，高层级组件里总会有大大小小的许多状态，以便控制基本组件的开/关、显示/隐藏等等。此外，除了控制基本组件的状态以外，高层级组件本身可能还承担着数据通信的功能，例如我们本次提到的异步请求和发送数据。在 React 中，状态<code>state</code>的更新会使得组件重新进行渲染（见<a href="https://react.docschina.org/docs/state-and-lifecycle.html">State & 生命周期</a>），有的时候我们只希望重新渲染这个组件的一部分组件（例如刚才所说的对话框），而有的时候我们希望重新请求数据（数据同步、表格翻页）全部刷新，于是我们通常会使用 <a href="https://zh-hans.reactjs.org/docs/hooks-effect.html">useEffect 钩子</a>对一些刷新操作添加限定，仅仅在某些变量修改的时候，才会重新执行该部分代码逻辑（在 React 官方文档中叫做<a href="https://zh-hans.reactjs.org/docs/hooks-effect.html#tip-use-multiple-effects-to-separate-concerns">关注点分离</a>）。<h2 id="问题"><a href="#问题" class="headerlink" title="问题"></a>问题</h2>所以对于一个又需要刷新数据，又需要控制对话框，而且获取数据要请求两次 api 的组件，就会变成这个样子（CallBack 版本）：<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { let [dialogState, setDialogState] = useState(false); // some states for dialogs let [renderData, setRenderData] = useState(null); // some states for rendering let [page, setPage] = useState(1); // some states which force data refresh useEffect(() => { fetchSomeData("url", {params: "Some Params"}, {config: "Some Configurations"}, (data) => { // callback for success let someProps = getSomeProps(data); fetchSomeData("url2", {params: someProps}, {config: "Some Configurations"}, (data) => { // funciton for process setRenderData(processing(data)); }, () => {}); }, (error) => { // callback for failure }); }, [page]); // fetch data only when page changes if (renderData === null) return null; return ( <> {/* equals to <React.Fragment> */} <Dialog someStates={dialogState}/> <Others data={RenderData}/> </> {/* equals to </React.Fragment> */} ); } </pre></td></tr></tbody></table></figure>于是这个组件的执行流程是这样子的：<ul><li>组件第一次渲染：执行<code>useEffect</code>，开启异步数据请求，此时并没有任何有效数据用于渲染，于是返回<code>null</code>不加载模型；</li><li>组件收取到信息：执行回调函数，对数据进行处理，并更新组件状态，此时仍未执行组件刷新，数据不变；</li><li>组件状态得到更新：组件状态变化，组件刷新，但不再执行<code>useEffect</code>；</li><li>（中间可能的）对话框状态变化：组件状态变化，组件刷新，但不再执行<code>useEffect</code>。</li></ul>这样存在的问题在于，<ul><li>回调函数过于复杂——函数体量太大在合作时难以理解，包装起来可能涉及数据传递的问题</li><li>回调函数嵌套——有可能在收到某些信息，还要基于这些信息继续发请求，那么回调函数可能嵌套多层</li></ul><h2 id="Promise-的意义"><a href="#Promise-的意义" class="headerlink" title="Promise 的意义"></a>Promise 的意义</h2>我感觉<a href="https://zhuanlan.zhihu.com/p/26523836">理解 JavaScript Promise</a>这篇文章写的还是不错的，使用 <code>Promise</code> 构造一个函数，这个 <code>Promise</code> 就可以管理这个函数的状态，以便后续任务在这个函数执行完毕后使用。所以现代的 fetch 函数都尽可能返回一个 <code>Promise</code>，以便我们使用 <code>Promise.then()</code> 这个方法以便对数据进行处理。所以上面的代码或许可以改成这个样子：<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { ... useEffect(() => { fetchSomeData("url", {params: "Some Params"}, {config: "Some Configurations"}).then((data) => { // funciton for process let someProps = getSomeProps(data); return fetchSomeData("url2", {params: someProps}, {config: "Some Configurations"}); }).then((data) => { // funciton for process setRenderData(processing(data)); }).catch((error) => { // function for failure }); }, [page]); // fetch data only when page changes ... } </pre></td></tr></tbody></table></figure>那么这样有没有实质性的减少代码层数？减少了，原先存在的嵌套调用现在变成了连续使用 <code>.then()</code>函数，使得硕大的处理层变得轻松的多。<h2 id="Async-和-await"><a href="#Async-和-await" class="headerlink" title="Async 和 await"></a>Async 和 await</h2>与上一节一样，先挂出一个链接用于学习：<a href="https://www.cnblogs.com/youma/p/10475214.html">【学习笔记】深入理解 async/await</a>。<code>await</code> 的出现带来了什么呢？<code>await</code> 使得获取的结果直接提取了出来，不再需要额外套一层函数用于执行。这样函数嵌套会更加少，而且也可以像同步的函数一样处理数据了。于是我们的代码会变得更加清楚，不会再像原来一样晦涩难懂。于是我们的代码可能变成这样子，如果想分开处理异常可以套两个 <code>try-catch</code>块：<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { ... useEffect(async () => { try { let data = await fetchSomeData("url", {params: "Some Params"}, {config: "Some Configurations"}); // funciton for process let someProps = getSomeProps(data); let anoData = await fetchSomeData("url2", {params: someProps}, {config: "Some Configurations"}); // funciton for process setRenderData(processing(anoData)); } catch (error) { // function for failure } // try-catch block is unnecessary if no error exist }, [page]); // fetch data only when page changes ... } </pre></td></tr></tbody></table></figure>但是这样 <code>Eslint</code> 组件是会报警告的——<blockquote>ESLint: Effect callbacks are synchronous to prevent race conditions. Put the async function inside:</blockquote>如果版本早于 React 16，可能会直接报错误——<blockquote>An effect function must not return anything besides a function, which is used for clean-up. It looks like you wrote useEffect(async () => …) or returned a Promise. Instead, write the async function inside your effect and call it immediately</blockquote>这是因为 <code>useEffect</code>是需要返回值来解决组件销毁/重建时的副作用清除的，而我们加上 <code>async</code> 关键字则会让这个函数返回一个 <code>Promise</code>，所以应该建一个普通的函数，然后在函数里面创建带有<code>async</code>关键字的函数，并立即调用。详见 <a href="https://juejin.cn/post/7029117054233870349">hooks 学习之 useEffect</a>。<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { ... useEffect(() => {(async () => { ... })()}, [page]); // fetch data only when page changes ... } </pre></td></tr></tbody></table></figure><h2 id="并行的数据请求"><a href="#并行的数据请求" class="headerlink" title="并行的数据请求"></a>并行的数据请求</h2>我们的请求可能没有前置要求，那么异步的数据获取我们怎么进行处理呢？一般来说，我们对于数据请求，难免存在请求失败的情况，所以常见的策略是哪部分到了先加载哪部分，报错的部分再进行重试或请求备用数据源，以免用户等待太着急。于是我们就可以建造多个<code>useEffect</code>函数，分别进行数据请求和处理，加上 <code>React</code> 的关注点分离策略，我们就可以实现部分数据的渲染。<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { let [dataA, setDataA] = useState(null); // data for Component A let [dataB, setDataB] = useState(null); // data for Component B useEffect(() => { fetchSomeData("urlA", {params: "Some Params"}, {config: "Some Configurations"}).then((data) => setDataA(data)); }, [page]); useEffect(() => { fetchSomeData("urlB", {params: "Some Params"}, {config: "Some Configurations"}).then((data) => setDataB(data)); }, [page]); return ( <> {/* equals to <React.Fragment> */} { dataA && <A data={dataA}/> } { dataB && <B data={dataB}/> } </> {/* equals to </React.Fragment> */} ); } </pre></td></tr></tbody></table></figure>如果我们对数据正确性有非常高的要求，要求必须所有数据到齐才能渲染的话，可以使用<code>Promise.all()</code>函数。<figure class="highlight jsx"><table><tbody><tr><td class="code"><pre>export default function Component(props) { let [dataA, setDataA] = useState(null); // data for Component A let [dataB, setDataB] = useState(null); // data for Component B useEffect(() => { let remoteA = fetchSomeData("urlA", {params: "Some Params"}, {config: "Some Configurations"}); let remoteB = fetchSomeData("urlB", {params: "Some Params"}, {config: "Some Configurations"}); Promise.all([remoteA, remoteB]).then((dataArray) => { let [first, second] = dataArray; setDataA(first); setDataB(second); }).catch((error) => someFunction(error)); }, [page]); return ( <> {/* equals to <React.Fragment> */} { dataA && <A data={dataA}/> } { dataB && <B data={dataB}/> } </> {/* equals to </React.Fragment> */} ); } </pre></td></tr></tbody></table></figure>

不知不觉博客已经开启接近两年了，一直以来本站使用的技术是阿里云全站加速+GitHub Pages 的部署方式。不过由于国内 CDN 回源 Pages 服务器还是存在着连接质量差的问题，在两周年之际，本站使用了基于 GitHub Actions + 宝塔 + 阿里云全站加速的搭建模式。<h2 id="好用的-GitHub-Actions"><a href="#好用的-GitHub-Actions" class="headerlink" title="好用的 GitHub Actions"></a>好用的 GitHub Actions</h2>Actions 是个好东西，一个月有 3000 分钟的私有仓库时长配额（GitHub Pro 或 GitHub Student Pack），普通用户也有 2000 分钟每月的私有仓库时长配额。值得一提的是，对于公开的仓库，GitHub Actions 是全免费、随便用的（单帐户同类镜像仅允许同时开启一个，否则会排队等待上一个 Job 执行完毕，单 Job 运行最长时间 6 小时）。相比于<code>Travis CI</code>之类的持续集成工具来说，GitHub Actions 对同平台的仓库相比更加具有便利性（至少 clone 个代码是真心快😂<img src="https://github.githubassets.com/images/icons/emoji/unicode/1f602.png?v8" aria-hidden="true" onerror="this.parent.classList.add('github-emoji-fallback')">）。Actions 不只是可以做 Release 导出、项目构建之类的操作，由于其定时运行的特性，常被大家用来渲染账户成就（如 star 超过 3k 的<a href="https://github.com/lowlighter/metrics">Metrics</a>，作者 icy 也部署了其自动生成<a href="https://github.com/icy-blue">个人 Profile</a>），<a href="https://github.com/zhangt2333/actions-SduElectricityReminder">自动体温填报</a>等操作。<h2 id="Hexo-类博客与-GitHub-Pages"><a href="#Hexo-类博客与-GitHub-Pages" class="headerlink" title="Hexo 类博客与 GitHub Pages"></a>Hexo 类博客与 GitHub Pages</h2>Hexo 是目前来说非常普遍使用的博客了，在 GitHub 上有许多主题，如本站使用的是<a href="http://blinkfox.com/">闪烁之狐</a>的<a href="matery">matery</a>主题，在此也再次向作者表示感谢。用户可以轻易通过几行代码就可以生成一个简单的博客，编写 markdown 的博客内容，并通过一句简单的<code>hexo deploy</code>或者<code>hexo d</code>就可以将自己博客部署到仓库中。虽然 Hexo 最近一直在更新，不过 Hexo 很多功能插件的依赖项，爆出了安全漏洞，如<code>hexo-renderer-marked</code>使用的<code>marked@^2.1.3</code>，爆出了<a href="https://github.com/advisories/GHSA-5v2h-r2cx-5xgj">GHSA-5v2h-r2cx-5xgj</a>和<a href="https://github.com/advisories/GHSA-rrrm-qjm4-v8hf">GHSA-rrrm-qjm4-v8hf</a>安全漏洞，而截至目前（2022 年 1 月 21 日）插件维护方尚未对该插件的依赖版本升级至<code>4.0.10</code>以上。为了更加的傻瓜式，GitHub 还提供了 Pages 服务，帮助直接将一个静态网站部署到<code>https://<username>.github.io/<repository>/</code>上。经过一段时间的自动部署，我们就可以访问自己刚刚部署好的博客界面了。GitHub Pages 可以满足绝大多数海外用户的使用需求，因为 Pages 对于一个简单的非商业项目来说配额已经十分充足——<blockquote>GitHub Pages sites are subject to the following usage limits:<ul><li>GitHub Pages source repositories have a recommended limit of 1GB. </li><li>Published GitHub Pages sites may be no larger than 1 GB.</li><li>GitHub Pages sites have a soft bandwidth limit of 100GB per month.</li><li>GitHub Pages sites have a soft limit of 10 builds per hour.</li></ul></blockquote>配额说明来自于 2022 年 1 月 21 日的<a href="https://docs.github.com/cn/pages/getting-started-with-github-pages/about-github-pages#usage-limits">GitHub Docs</a>，不过对于国内用户来说更大的问题是，由于海外带宽的限制以及一些原因，国内用户访问 GitHub 及 GitHub Pages 经常出现连接问题。自己好不容易搭建的博客，发现国内的朋友们，尤其是不太会科学使用网络的朋友们，打不开自己的博客，可能也会非常沮丧吧😢<img src="https://github.githubassets.com/images/icons/emoji/unicode/1f622.png?v8" aria-hidden="true" onerror="this.parent.classList.add('github-emoji-fallback')">😱<img src="https://github.githubassets.com/images/icons/emoji/unicode/1f631.png?v8" aria-hidden="true" onerror="this.parent.classList.add('github-emoji-fallback')">。<img src="../images/2022012101.jpg" alt="真·二次元" style="zoom: 33%;"><h2 id="使用-CDN-分发与加速"><a href="#使用-CDN-分发与加速" class="headerlink" title="使用 CDN 分发与加速"></a>使用 CDN 分发与加速</h2>既然 GitHub Pages 打不开，我们可能就想，有没有其他更合适的办法，让大陆用户正常地访问自己的网页呢？当然有——icy 和他的朋友<a href="https://www.kskun.com/">KS</a>就不约而同地使用了 CDN 分发和加速。内容分发网络 CDN(Content Delivery Network)可以将用户的请求负载均衡到不同的缓存节点，当用户的请求到达时，CDN 将判断访问者 IP，将请求按优先级分发给源站或最近缓存节点，以加快用户的请求速度。以当前的场景来说，在网站设置了 CDN（设置解析、源站、设置缓存目录及后缀、设置缓存过期时限、配置 HTTPS 等）后，用户请求到 CDN 时，CDN 会先判断是否存在缓存，有缓存将请求转给缓存，没有缓存会由 CDN 请求源站，按照配置进行缓存，并将结果返回给用户。由于 CDN 和 Pages 的连接是畅通的，用户和 CDN 的连接是畅通的，于是通过 CDN 作为跳板，实现了 GitHub Pages 的高速访问。自然，也付出了 CDN 的使用费用（见<a href="./CDN%E6%98%AF%E4%BB%80%E4%B9%88%E5%8F%AF%E4%BB%A5%E5%90%83%E5%90%97.md">CDN 是是什么可以吃吗</a>）。值得注意的是，如果使用国内 CDN，且对国内用户提供服务时，要求域名进行 ICP 备案。<h2 id="使用服务器部署博客"><a href="#使用服务器部署博客" class="headerlink" title="使用服务器部署博客"></a>使用服务器部署博客</h2>既然使用国内 CDN 了，何不直接使用国内的服务器呢~在 2021 年双十一期间<del>（活动已结束，价格供参考）</del>，腾讯云打出了 2 核 4GB 8Mbps 月流量 1200GB 的轻量应用服务器一年 70 元、三年 198 元的活动，吸引了许多建站开发者。按购买 3 年计算，月均消费 5.5 元，是非常适合学生党“折腾”的。<img src="../images/2022012103.png" alt="腾讯云 2021 年双十一活动界面" style="zoom: 67%;">一般来说，我们的代码编辑仍然还是在自己的电脑上，而服务器仅仅是对于 Hexo 生成的静态文件的展示（一般来说不会在服务器上使用 Node.js 展示 Hexo 服务，因为对于静态网站，在线解析生成其实是一种浪费）。此时我们其实就可以使用上面所说的<code>hexo d</code>命令，把静态网站部署到<code>Gitee</code>上（因为服务器去访问 GitHub 还是非常困难的），然后在服务器上同步拉取即可。同步拉取的方式，最简单的办法就是在服务器上设置循环脚本，每隔一段时间拉取仓库`。<figure class="highlight bash"><table><tbody><tr><td class="code"><pre>git fetch --all git reset --hard origin/<branch> git pull </pre></td></tr></tbody></table></figure>由于 Hexo 的部署是强制推送，不存储过往的界面，以减少整个仓库的大小，我们在拉取仓库的时候使用强制覆盖本地仓库的方式进行更新。考虑到 SSH 会话运行的程序在 SSH 连接断开后不太稳定，我们可以使用终端复用器 Tmux(terminal multiplexer)，使得脚本在后台使用。关于 Tmux，在<a href="https://www.ruanyifeng.com/blog/2019/10/tmux.html">阮一峰博客</a>那里有一个很好的介绍，我们可以通过<code>tmux new -s <session-name></code>创建一个新的会话，然后在会话里运行 Python 脚本，一个简单的 Python 脚本可能像这样：<figure class="highlight python"><table><tbody><tr><td class="code"><pre>import os import time import threading while True: time.sleep(60) # 60 seconds os.system("git fetch --all") os.system("git reset --hard origin/master") os.system("git pull") </pre></td></tr></tbody></table></figure>当然读者也可以通过写 bash 脚本解决问题。我们在刚刚建立的 session 中运行脚本后关闭 SSH 会话或按下<code>Ctrl + B d</code>将会话切回到后台，即可实现脚本的后台运行。<h2 id="WebHook"><a href="#WebHook" class="headerlink" title="WebHook"></a>WebHook</h2>循环拉取仓库好像挺傻的，不美观，那能不能让仓库主动去推送更新消息呢？WebHook 可以帮助我们了解这样的信息。WebHook 是一种 API 概念，当仓库有变动时（新 Push、新 PR、新 Issue 等等），代码托管平台会给仓库预留的链接发送 POST 请求。我们一般在服务器的某个端口，监听这类的 POST 请求（用 Node.js、Python 等程序可以很快地编写一个监听 POST 请求的 Server，Python + Flask 的实现可以参考<a href="https://www.cnblogs.com/Alin-2016/p/7422987.html">python+flask：实现 POST 接口功能</a>，Go 语言可以参考<a href="https://blog.csdn.net/qq_27312939/article/details/110632297">GO 接收 GET/POST 参数以及发送 GET/POST 请求</a>，Node.js 可以参考<a href="https://blog.csdn.net/w390058785/article/details/79770540">【node.js】处理前端提交的 POST 请求</a>，其他语言不再列举）。根据<a href="https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads">GitHub</a>和<a href="https://gitee.com/help/articles/4271">Gitee</a>的文档，我们可以在服务器上解析平台上发生的事件，并进行一定的处理。以监测平台有新提交自动拉取代码这个需求来说，我们可以设置相关的触发器，设置相关的钩子地址，并设置鉴权（以免其他用户滥发），当代码托管平台的仓库有了新提交，我们的服务器则会收到 POST 消息，以便实现。作为 POST 的回应，建议在服务器上回复 JSON，并设置<code>HTTP status 200</code>，以免部分平台认定推送失败。<h2 id="宝塔的-WebHook"><a href="#宝塔的-WebHook" class="headerlink" title="宝塔的 WebHook"></a>宝塔的 WebHook</h2>不愿意自己写代码监听？宝塔软件商店里的<code>宝塔WebHook</code>可以帮你实现 WebHook 的接收。在宝塔的软件商店中，搜索<code>WebHook</code>，找到<code>宝塔WebHook</code>，便可以在里面添加钩子。<img src="../images/2022012104.png" alt="宝塔 WebHook 界面" style="zoom: 80%;">添加完后，我们可以看到自己添加钩子的情况，包括钩子名称、添加时间、近期调用、调用次数等信息。我们还可以查看密钥查看钩子的密钥，以便鉴权。在查看密钥的界面，宝塔提供了一个示例的链接，其中参数包括密钥和脚本参数，我们可以按需进行调整，并把最后的链接放在代码仓库-设置-WebHook 的相应位置（由于我们的鉴权密钥在 URL 的参数上，所以对于 GitHub 和 Gitee 来说，密码处可以随便写）。<img src="/../images/2022012105.png" alt="宝塔WebHook界面"><img src="/../images/2022012106.png" alt="宝塔WebHook查看密钥界面">下面是 GitHub 和 Gitee 的 WebHook 设置示例：<img src="../images/2022012107.png" alt="GItHub的WebHook设置示例" style="zoom: 50%;"><img src="../images/2022012108.png" alt="Gitee的WebHook设置示例" style="zoom:50%;">做到这里，我们就可以让服务器自动跟进代码仓库的更新了。<h2 id="使用-GitHub-Actions-实现静态界面的生成"><a href="#使用-GitHub-Actions-实现静态界面的生成" class="headerlink" title="使用 GitHub Actions 实现静态界面的生成"></a>使用 GitHub Actions 实现静态界面的生成</h2>每次我们发现，自己的静态界面确实已经保存在代码仓库中了，而原始文件却没能保存。有的朋友会选择再建一个仓库专门提交原始文件，先提交静态界面，再提交原始文件，提交两次可能总是会遗漏，那有没有只提交一次的办法呢？答案自然是肯定的，我们可以通过使用 GitHub Actions 实现静态界面的生成。下面是一个简单的配置文件，修改用户名邮箱等信息后，将其放在原始博客仓库的<code>.github/workflows/</code>内，以 yml 格式为文件名后缀，配置就已经部署好了——吗？<figure class="highlight yaml"><table><tbody><tr><td class="code"><pre>name: Hexo Deploy on: # 如果你的默认 branch 是 master，将下面的 main 改为 master push: branches: [ main ] pull_request: branches: [ main ] workflow_dispatch: jobs: deploy-github: runs-on: ubuntu-latest steps: # 设置服务器时区为东八区 - name: Set time zone run: sudo timedatectl set-timezone 'Asia/Shanghai' - name: Checkout source uses: actions/checkout@v2.4.0 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: '12' - name: Setup Hexo run: | npm install hexo-cli -g npm install hexo-deployer-git --save npm install - name: Setup Git env: ACTION_DEPLOY_KEY: ${{ secrets.HEXO_DEPLOY_KEY }} run: | mkdir -p ~/.ssh/ echo "$ACTION_DEPLOY_KEY" > ~/.ssh/id_rsa chmod 700 ~/.ssh chmod 600 ~/.ssh/id_rsa ssh-keyscan github.com >> ~/.ssh/known_hosts git pull git config --global user.email "<email>" git config --global user.name "<username>" # 如果在自己的_config.yml已配置，则直接运行最后两条命令即可 - name: Deploy run: | cat >> _config.yml <<EOF # 自动部署配置 deploy: type: git repo: git@github.com:<username>/<username>.github.io.git branch: hexo EOF hexo clean hexo deploy </pre></td></tr></tbody></table></figure>去部署一个仓库，我们当然是要提供一些权限让它有权更改目的仓库，我们到目的仓库<code><username>.github.io</code>的设置界面，找到<code>Deploy keys</code>后在右上角添加一对公钥（为了避免后期权限混乱的麻烦，建议新建一对新的公钥私钥对，公钥私钥的生成方式可以参考<a href="https://gitee.com/help/articles/4181">Gitee 的帮助文档</a>），将公钥放在<code>Key</code>区域，标题任取即可，注意勾选<code>Allow write access</code>，否则仅有只读权限，仍然无法部署。<img src="/../images/2022012109.png" alt="添加仓库部署可信公钥">现在目的仓库就认可了这个公钥，接下来我们要把私钥交给源仓库。直接放在仓库内是不保险的，因为我们 clone 了这个仓库就可以看到私钥明文，即便是私有仓库但是如果存储该仓库的主机被攻破，仍然可以得到私钥的明文。因此我们应该放在一个更加合适的位置，就比如仓库设置中的<code>Secret</code>区域。<img src="/../images/2022012110.png" alt="仓库 Secret 区">我们在右上角添加新密钥，命名为<code>HEXO_DEPLOY_KEY</code>（如修改需要同步修改上面 yml 文件的名称）。密钥粘贴时，需将<code>-----BEGIN OPENSSH PRIVATE KEY-----</code>之类的标识行一同复制，在<code>-----END OPENSSH PRIVATE KEY-----</code>后最好换一行（即光标在密钥下一行）。请注意，密钥写入后无法查看，只能覆盖，如丢失需要重新生成公钥私钥对。<img src="/../images/2022012111.png">此时，用于部署的仓库就有了部署权限，在每次用户的 Push 操作和 PR 操作后，可以把生成的静态目录推送的目标仓库了。<h2 id="放在最后"><a href="#放在最后" class="headerlink" title="放在最后"></a>放在最后</h2>篇幅有点长了，剩下的当作下期预告吧——<ul><li>使用 GitHub Actions 实现仓库从 GitHub 到 Gitee 的同步</li><li>使用 Gitee Pages</li><li>做一个合适的负载均衡</li><li>使用 Lint-md 让博客内容排版更加规范</li></ul>