Next.js 提供了多种渲染策略（SSG、SSR、ISR、CSR），每种策略适用于不同的场景。以下是它们的核心区别、实现方式及最佳实践：
1. SSG（Static Site Generation，静态生成）
核心特点
- 生成时机：在构建时（
next build）生成静态 HTML。
- 数据获取：通过
getStaticProps获取数据，支持预渲染所有页面。
- 适用场景：内容不经常变化的页面（如博客、文档、营销页）。
- 优点：加载最快、SEO 友好、CDN 缓存友好。
- 缺点：无法实时更新内容，需重新构建才能更新。
实现代码
2. SSR（Server-Side Rendering，服务端渲染）
核心特点
- 生成时机：每次页面请求时在服务端动态生成 HTML。
- 数据获取：通过
getServerSideProps在请求时获取最新数据。
- 适用场景：需要实时数据的页面（如用户仪表盘、实时股价）。
- 优点：内容始终最新，支持个性化渲染（如基于 Cookie 的权限验证）。
- 缺点：TTFB（首字节时间）较慢，服务端压力大。
实现代码
3. ISR（Incremental Static Regeneration，增量静态再生）
核心特点
- 生成时机：SSG 的扩展，允许在运行时按需重新生成静态页面。
- 数据获取：在
getStaticProps中设置revalidate参数（秒），触发条件： • 初次访问时生成静态页面。 • 后续访问时，若超过revalidate时间，后台重新生成页面。
- 适用场景：内容更新频率适中的页面（如电商产品页、新闻列表）。
- 优点：兼具 SSG 的速度和 SSR 的更新能力，减轻服务端压力。
- 缺点：再生成期间用户可能看到旧数据。
实现代码
4. CSR（Client-Side Rendering，客户端渲染）
核心特点
- 生成时机：在客户端浏览器中通过 JavaScript 渲染内容。
- 数据获取：通过
useEffect或SWR在组件挂载后获取数据。
- 适用场景：交互性强、无需 SEO 的页面（如用户后台、管理面板）。
- 优点：减少服务端负载，支持动态交互。
- 缺点：首屏加载慢，SEO 不友好，依赖客户端 JavaScript。
实现代码
5. 对比表格
特性 | SSG | SSR | ISR | CSR |
生成时机 | 构建时 | 每次请求时 | 构建时 + 按需再生 | 客户端运行时 |
数据实时性 | 低（需重新构建） | 高（实时） | 中等（可配置更新间隔） | 高（动态获取） |
SEO 支持 | ✅ 最佳 | ✅ 良好 | ✅ 良好 | ❌ 差（需额外处理） |
首屏加载速度 | ⚡️ 最快 | ⏳ 较慢（依赖服务端） | ⚡️ 快（缓存优先） | ⏳ 慢（需加载 JS） |
适用场景 | 静态内容 | 实时数据 | 频繁更新但非实时内容 | 交互复杂、无需 SEO |
服务端压力 | 无 | 高 | 低 | 无 |
6. 混合使用策略
Next.js 允许在同一个项目中灵活组合多种渲染方式：
• SSG + CSR：首屏静态渲染，交互部分客户端加载（如博客的评论模块）。
• SSR + ISR：动态页面初次 SSR，后续通过 ISR 缓存（如新闻详情页）。
• App Router 优化：在
app 目录中，使用 React Server Components 减少客户端 JS 体积。示例：混合 SSG 和 CSR
7. 选择策略的决策树
- 是否需要 SEO？ • ✅ 是 → 使用 SSG、SSR 或 ISR。 • ❌ 否 → 使用 CSR。
- 数据是否频繁更新？ • ✅ 是 → 使用 SSR 或 ISR。 • ❌ 否 → 使用 SSG。
- 是否有个性化内容？ • ✅ 是 → 使用 SSR。 • ❌ 否 → 使用 SSG 或 ISR。
总结
- SSG：优先用于内容稳定、SEO 关键的页面。
- SSR：用于实时数据或个性化内容。
- ISR：平衡速度与更新频率，适合大规模内容站点。
- CSR：用于交互复杂、无需 SEO 的功能模块。
- 混合使用：结合不同策略，最大化性能与功能灵活性。
系列文章
Next.js 中的 App Router（应用路由）和 Page Router（页面路由）是两种不同的路由架构，主要区别在于 目录结构、功能特性、数据加载方式及布局管理。以下是详细对比：
1. 目录结构与路由定义
特性 | App Router (Next.js 13+) | Page Router (Next.js 12 及更早) |
目录位置 | app 目录 | pages 目录 |
路由生成方式 | 基于文件夹路径定义路由（如 app/about/page.js → /about） | 基于文件名自动生成路由（如 pages/about.js → /about） |
动态路由 | 文件夹名用 [param] 标记（如 app/posts/[id]/page.js） | 文件名用 [param] 标记（如 pages/posts/[id].js） |
API 路由 | 支持 API 路由（如 app/api/route.ts） | 使用 pages/api 目录 |
2. 核心功能差异
（1）布局与嵌套路由
- App Router
• 嵌套布局：通过
layout.js 文件定义层级布局，自动包裹子页面（如 app/dashboard/layout.js 包裹 app/dashboard/page.js）。• 模板与错误处理：支持
template.js（局部刷新布局）和 error.js（错误边界）。• 流式加载：通过
loading.js 定义页面加载时的骨架屏。- Page Router
• 全局布局：需通过
_app.js 和 _document.js 自定义全局布局，无法自动嵌套。• 手动处理嵌套：需在组件内显式引入布局（如
<Layout><Page /></Layout>）。（2）数据加载
- App Router
• 服务端数据获取：组件可直接使用
async/await 获取数据（默认为 React Server Component）。• 并行加载：通过
<Suspense> 分块加载多个数据源。• 动态 SEO：通过导出
metadata 对象动态设置页面标题、描述等。- Page Router
• 数据方法：需使用
getStaticProps（SSG）、getServerSideProps（SSR）或 getInitialProps（混合渲染）。• SEO 静态化：需手动在
_document.js 或页面组件内设置 <Head> 标签。3. 渲染模式与性能
特性 | App Router | Page Router |
默认渲染模式 | 支持 React Server Components（服务端组件优先） | 默认客户端渲染（需手动选择 SSG/SSR） |
流式渲染（Streaming） | 支持分块传输内容，优先显示关键部分 | 需自行实现（如使用 React.lazy） |
静态生成（SSG） | 通过 generateStaticParams 预生成动态路由 | 通过 getStaticPaths 预生成路由 |
4. 混合使用与迁移
- 共存支持：Next.js 13+ 允许
app和pages目录共存，可逐步迁移旧项目。
- 优先级：若同一路由在
app和pages中均有定义，app目录的页面优先。
- 适配性：部分第三方库（如
next-auth）可能需调整配置以兼容 App Router。
5. 适用场景对比
场景 | App Router 优势 | Page Router 优势 |
新项目 | ✅ 推荐使用（功能更现代，性能更优） | ❌ 不推荐 |
旧项目维护 | ⚠️ 需逐步迁移 | ✅ 适合保留原有结构 |
复杂布局需求 | ✅ 嵌套布局和模板支持完善 | ❌ 需手动管理嵌套 |
服务端组件需求 | ✅ 默认支持服务端渲染和数据获取 | ❌ 需通过 getServerSideProps 实现 |
总结
- App Router 是 Next.js 的未来方向，提供更强大的布局管理、流式渲染和服务端组件支持，适合追求高性能和现代特性的项目。
- Page Router 适合维护旧项目或简单应用，但功能扩展性较弱。
- 建议新项目直接采用 App Router，旧项目可逐步迁移以利用新特性。
系列文章
Serverless（无服务器架构）是一种云计算模型，其核心思想是开发者无需关注底层服务器的运维、扩容和资源分配，只需专注于编写业务代码。云服务商（如 AWS、腾讯云、阿里云）会动态管理计算资源的分配，按需执行代码并自动伸缩。在前端开发中，Serverless 主要用于解决后端服务部署、API 管理和静态资源托管等问题，尤其适合结合 SSR（服务端渲染）技术使用。以下是具体解析：
1. Serverless 的核心特点
- 无服务器管理：开发者无需自行配置服务器或维护基础设施，云平台自动处理资源调度。
- 事件驱动：代码通过 HTTP 请求、数据库变更等事件触发执行（如用户访问页面触发 SSR 渲染）。
- 按需付费：根据实际代码执行时间和资源消耗计费，空闲时不产生费用。
- 自动伸缩：流量激增时自动扩容，避免因服务器性能不足导致服务中断。
2. 前端开发中 Serverless 的典型应用场景
（1）服务端渲染（SSR）
- 优化首屏加载与 SEO：通过 Serverless 函数（如 AWS Lambda、腾讯云 SCF）动态生成 HTML，提升页面加载速度和搜索引擎友好性。
示例：Next.js 框架的 SSR 页面可部署为云函数，每个页面路由对应一个独立的函数。
- 与静态资源分离：将渲染逻辑放在云函数中，静态资源（如图片、CSS）托管至对象存储（如 COS、S3），通过 CDN 加速。
（2）API 服务
- 轻量级后端：前端开发者可用 Node.js 编写 API（如 Express、Koa），直接部署为 Serverless 函数，替代传统后端服务器。
- 快速集成云服务：通过 Serverless 组件直接调用数据库、消息队列等云服务，无需自行搭建中间件。
（3）静态网站托管
- 自动化部署：Vercel 等平台支持将 Next.js、Nuxt.js 等前端框架的构建产物自动托管到全球 CDN，并绑定自定义域名。
- CI/CD 集成：关联代码仓库后，每次 Git Push 自动触发构建和部署流程。
3. Serverless 对前端的核心价值
- 降低运维成本：无需学习 Linux 或 Nginx 配置，专注业务代码。
- 快速迭代：通过 Serverless Framework 或 Vercel CLI 实现一键部署，缩短开发周期。
- 成本可控：小型项目可享受免费额度（如腾讯云每月 40 万 GBs 函数资源）。
- 生态兼容性：支持主流框架（Next.js、Nuxt.js）、语言（Node.js、Python）和云平台（AWS、阿里云、腾讯云）。
4. 实践注意事项
- 冷启动问题：函数首次调用时需初始化环境，可能导致延迟（可通过预置并发缓解）。
- 代码体积限制：云函数代码包通常需压缩至 50MB 以内，需剔除开发依赖（如
npm install --omit=dev）。
- 环境适配：部分云平台默认 Node.js 版本较低，需自行升级或通过 Layer 功能绑定运行时。
- 本地调试：使用 Serverless Framework 或 IDE 插件模拟云环境进行测试。
5. 主流部署方案示例
以 Next.js 应用为例：
- Vercel 托管：零配置部署，自动识别路由和 API，适合个人项目。
- 腾讯云 Web 函数：通过
serverless.yml配置入口文件和资源，支持自定义域名和 CDN。
- AWS Lambda：利用
@vercel/next构建器将页面拆分为独立函数，优化性能和资源利用率。
总结
Serverless 为前端开发提供了“无运维化”的可能性，尤其适合需要快速迭代、低成本运维的 SSR 应用和轻量级 API 服务。尽管存在冷启动等挑战，但随着云平台优化和工具链完善（如 Cloud Studio 的一键部署），它已成为现代前端工程化的重要方向。
系列文章
]]>Next.js 中客户端组件（Client Components）和服务端组件（Server Components）的核心区别在于运行环境、功能特性及适用场景，以下是详细对比：
1. 运行环境与渲染方式
- 服务端组件
• 环境：仅在服务器端运行，生成静态 HTML 发送到客户端。
• 渲染：支持静态渲染（默认）、动态渲染（需调用
fetch 等 API）和流式渲染（分块加载内容）。• 示例代码：直接获取数据并返回 HTML，无需客户端交互逻辑。
- 客户端组件
• 环境：在浏览器中运行，支持交互逻辑和浏览器 API（如
window、localStorage）。• 渲染：首次加载时由服务端生成 HTML 预览，随后通过客户端 JavaScript 进行 Hydration（水合）以实现交互性。
• 示例代码：使用
useState 管理状态并响应用户操作。2. 功能特性
特性 | 服务端组件 | 客户端组件 |
数据获取 | 可直接访问数据库、API 或敏感数据。 | 需通过客户端请求（如 fetch），数据可能暴露。 |
React Hooks | 不支持 useState、useEffect 等。 | 支持所有 React Hooks。 |
浏览器 API | 无法访问。 | 可访问 window、document 等。 |
性能优化 | 减少客户端 JS 体积，提升 SEO 和首屏加载速度。 | 增加客户端 JS 体积，但支持动态交互。 |
嵌套规则 | 可包含客户端组件。 | 不可嵌套服务端组件（仅能通过 Props 传递数据）。 |
3. 适用场景
- 服务端组件优先使用的情况：
• 静态内容展示（如博客文章、产品列表）。
• 需要直接访问数据库或敏感数据的场景。
• SEO 优化需求高的页面。
- 客户端组件优先使用的情况：
• 用户交互（如表单提交、按钮点击）。
• 动态状态管理（如购物车、计数器）。
• 依赖浏览器 API 的功能（如动画、地理位置）。
4. 混合使用与数据传递
- 组合方式：服务端组件可通过 Props 将数据传递给客户端组件。例如：
- 限制：客户端组件无法直接导入服务端组件，需通过 Props 或占位符传递。
5. 性能与安全
- 服务端优势：
• 缓存渲染结果，减少重复请求。
• 敏感逻辑（如数据库查询）保留在服务端，避免泄露。
- 客户端劣势：
• 增加客户端 JS 体积，可能影响加载速度。
• 需谨慎处理用户输入和敏感数据。
总结
服务端组件和客户端组件在 Next.js 中形成互补：
• 服务端组件 侧重于性能优化、数据安全与静态内容渲染。
• 客户端组件 专注于交互性和动态功能。
合理混合使用两者（如服务端获取数据后传递给客户端处理交互），可构建高效且用户友好的应用。
系列文章
2024年度个税汇算退税，从 3月21 号开始不需要预约了，然后抓紧时间对 2024 年的个税进行汇算申报，说不定还能退点税呢。
1、全年一次性奖金计税方式的选择
趁着周末的时间，打开了个税 APP进行了一番操作，其中 24 年因为有一项是奖金，可以尝试选择 计税方式 ，两种计税方式对比一下，在最后一步查看退税或者需要补税的金额大小，选择最优解。
2、税务审核不通过
昨天收到短信通知，告知审核不通过。查看个税 APP 审核状态，有如下信息：“由于您申报的收入存在待核实的事项，且纳税人年度汇算时申报的劳务报酬总收入小于本年度代开的劳务发票（不含汇总代开发票）总金额，故不予同意本次退税申请。”
搜索有效信息，审核不通过的这个原因的意思是：2024年度代开了劳务发票，但是扣缴义务人未代扣代缴或少代扣代缴了劳务报酬所得的个人所得税，所以需要您更正年度申报，自行添加未申报或少申报的劳务报酬收入。
仔细查看劳务报酬所得，大概率是 京粉返利 导致的数据有出入了。
有其他人遇到了同样的情况，具体就是 “相关情况为23年个税记录申报后，发票延期至24年开具导致。因为开票与申报时间不匹配的原因导致出现此提醒，实际对应金额的收入平台前期均已正常申报。当前可反馈兆盈侧协助提供说明文件，待出具后您可将说明文件上传至个税APP推送补正材料入口(无入口可联系主管税局沟通推送补正材料入口)。如您需兆盈侧协助提供相应说明材料信息， 可填写下方问卷信息以便协助处理。”
京东返利 23 年的发票延期到 24 年开具导致的。
3、税务审核不通过解决办法
如果 申报的劳务报酬总收入 和 本年度代开的劳务发票总金额 差别不大的话，可以如下解决。
3.1、查看本年度代开的劳务发票总金额
登录个人所得税APP，点击【办&查】，下滑到【发票管理】模块，选择【我的票夹】。
点击【我销售的】—【筛选】，开票日期选择【自定义】，填写汇算年度（一定要自定义选择时间，2024-01-01—2024-12-31），发票类型分别选择【数电票】和【税控发票】，其他默认【全部】，点击【确定】后进行查询，统计代开发票总金额。
统计本年度代开发票总金额可以有个技巧，在我的票夹下选择批量管理，把所有的全选，左下角显示即是 24 年度代开发票总金额。
3.2、查看申报的劳务报酬总收入
申报的劳务报酬总收入 这个比较容易看到，在进行申报的时候点进劳务报酬选项内，有金额合计即是 24 年申报的劳务报酬总收入。
3.3、新增一笔劳务报酬，重新申报
第一次申报审核没有通过的原因，就是申报的劳务报酬总收入【78.06元】小于本年度代开的劳务发票总金额【122. 83 元】，也就是这两个金额对不上。
要解决这个问题，可以在劳务报酬这个页面中，右上角点击新增，点击新增一项劳务报酬所得，新增的金额为 44.77 元【122.83-78.06】，这个根据自己实际情况填写。
新增页面的备注可以参考如下填写：
购物返利未申报部分差额
支付人：宿迁兆盈商服科技有限公司
支付地址：江苏省，宿迁市
价税合计122.83元
已申报金额78.06元
差额44.77元
识别号：91321311MA1X716Q06
3.4、第二天成功审核通过
将以上的重新申报提交之后，第二天查看申报记录，已经成功审核通过啦，下一步就是美美的等着退税到账即可。
utterances 是一个轻量级的评论插件 Utterances，基于 GitHub Issues 构建，无广告、无跟踪、开源且永久免费。它通过 GitHub OAuth 流程授权用户发表评论，所有数据存储在 GitHub 中，支持多种页面与 Issue 的映射方式，并提供多种主题自定义选项。
1、utterances工作原理
utterances 是基于 GitHub issues 构建的轻量级评论小部件，所有的评论信息也即是存储在 Github issues 中的，使用 GitHub issues管理博客的评论等。
当博客页面中 utterances 的组件加载时，GitHub issues搜索API将根据
url，pathname或title找到与页面关联的 issues。如果我们找不到与该页面匹配的issue，那么utterances 机器人会在第一次发表评论时自动创建 issue。用户要发表评论，必须使用Github Oauth授权登录，用户在博客下面发布评论，实质上是在对应的GitHub issue上发表评论。
2、utterances 优点
最主要的优点还是轻量接入，utterances插件通过 GitHub OAuth 授权用户发表评论，或者用户可以直接在 GitHub Issue 上评论。
另外，还有如下特点：
- 支持多种页面与 Issue 的映射方式，如根据页面路径名、URL、标题或 Open Graph 标题等自动匹配或创建 Issue。
- 可配置特定 Issue 编号或自定义标题关键词以匹配 Issue，同时支持为创建的 Issue 添加标签。
- 提供多种主题选项，可以定制样式，并通过简单的 script 标签将 Utterances 集成到博客中。
3、utterances 接入步骤
3.1、创建仓库并安装 utterances
1、然后需要创建一个公开的 github repo，接入utterances之后该仓库的 issues 用于存储博客的评论。
2、在你 github repo 中安装 ，点击左边的链接安装到你 账号中，安装之后可以在用
户设置的 Application 中查看已经安装。
然后点击 Configure 配置按钮，确保第一步中的 github repo打开了对 utterances 的操作权限。
3.2、代码配置到 blog 文件中
打开 ‣，在configuration 中配置 github repo 地址。
注意配置的格式是 owner/repo，其中 owner 是 account name，也就是你 github url中的name。
然后会得到要嵌入到 blog 系统中的一段代码，根据blog 不同的技术实现，粘贴到相应的博客模板位置即可。
使用
.utterances和 .utterances-frame选择器自定义布局和样式。参考资料
什么是XAPK?
XAPK文件是一种文件扩展格式，它与APK格式有些相似，但也有所不同。
可以这么理解： XAPK文件= APK文件+ OBB数据文件。（OBB（Opaque Binary Blob）文件格式，是安卓游戏通用数据包）包含了单独的APK文件和OBB cache assets文件。
Google Play 商店要求压缩APK大小不超过100 MB。用户通过Google Play Console每次上传一个APK时可以选择附带一到两个.obb格式的文件，这种.obb文件可以是大小不超过2 GB的任何格式（ZIP，PDF，MP4等）。
XAPK格式确保用户可以顺利下载大型文件避免中断或失败。
为什么使用XAPK?
APK文件是在Android智能手机上安装应用程序的标准格式。由于大小原因，通常必须单独获取OBB文件。
XAPK是一种zip格式，可将所有应用程序数据保存在一个文件中，以方便安装。如果您要下载XAPK文件，则该文件同时包含OBB和APK部分，以及同一存储库中的缓存，图标和其他信息。
但是，XAPK文件不像APK文件那样，可以通过手机上的默认安装器直接安装到安卓手机上。需要找一些三方工具，比如 XAPK Installer，或者 APKPure。
安装XAPK的方法和工具
1、工具 xapk installer
可以到 Google Play 上搜索 xapk installer，安装好之后扫描xapk 的文件，或者手动选择到 xapk 的路径，然后打开即可安装。
2、工具Install Buddy: XAPK, APKs
同上，可以在 google 应用商店搜索该应用。
3、工具ApkPure
APKPure XAPK 安装器可以通过最便捷的方式帮你一键安装和管理安卓设备上的APK和XAPK文件。
可以帮你集中浏览和管理所有XAPK和APK文件，同样也可以通过最简单的方式一键更新或者卸载任意XAPK和APK文件。
需要注意的是，要为 xapk installer 等这些工具打开文件访问、应用安装（未知来源）的权限。
除了上一篇介绍的 使用 Github Action自动执行Vercel 部署 使用Deploy Hooks 的方式进行部署之外，还可以有更复杂的场景。
比如可以将 Vercel 与 GitHub Actions 一起使用作为您的 CI/CD 提供程序，在每次推送代码时生成预览部署，并在代码合并到
main分支时部署到生产环境。这种则需要使用到 Vercel 的访问令牌 access_token 等。
1、获取相关访问令牌
获取
VERCEL_TOKEN、VERCEL_ORG_ID和VERCEL_PROJECT_ID 相关token。1.1、获取 Vercel api 访问令牌VERCEL_TOKEN
在 个人账号设置 → Token 菜单下，创建 api 访问令牌，也即是
VERCEL_TOKEN。
1.2、获取VERCEL_PROJECT_ID
在Vercel 具体项目下， 项目设置 下找到 Project Id。
1.3、获取VERCEL_ORG_ID
- 使用命令行
npm i -g vercel安装Vercel CLI并运行vercel login
- 在新建文件夹中，运行
vercel link以创建一个新的 Vercel 项目，或者是已有的Git 项目，会提示✅ Linked toxxx-projects/next-starter-example(created .vercel)并生成.vercel 文件夹。
- 在生成的.vercel文件夹中，从project.json
{"projectId":"prj_xxx","orgId":"team_xxx"}保存projectId和orgId。
在Account Setting→General 菜单下，有
Vercel ID[This is your user ID within Vercel.] API Token，是否可以作为VERCEL_ORG_ID？[未验证]
1.4、配置到 Github 中
将以上
VERCEL_TOKEN、VERCEL_ORG_ID和VERCEL_PROJECT_ID添加到 GitHub 项目的 actions secret 配置中。
2、配置 Github Actions
当代码推送到非 main 分支时，生成预览部署：
当代码推送到 main 分支时，生成正式部署：
3、借助marketplace 上的 Github Actions 实现
也可以借助一些已经实现好的 actions 来实现我们的需求。比如：
3.1、代码推送或者发起 pull request 时触发
3.2、另一例：deploy-to-vercel-action
使用 GitHub Actions 将您的项目/站点部署到Vercel。在何时部署站点方面，它比 Vercel 的 GitHub 集成提供了更多的自定义功能。使用 GitHub Actions Events，您可以选择部署每个提交，仅在新版本上或甚至在 cron 计划上部署。该操作还可以部署每个 PR 并使用自定义预览 URL 对其进行评论。它使用 Vercel CLI，也可以自动在 GitHub 上创建部署。
参考资料
之前本网站部署在 Netlify 上的，有过一篇文章使用 Github Action自动执行 Netlify 部署。 以解决每周自动部署网站的功能，详细可点击查看。
最近想查看下国内访问网站的速度情况，所以使用 itdog ping 工具进行了测试，发现国内的情况十分不理想。
所以萌生了起换到 vercel 上的想法，并且 vercel 也有 cdn 功能了，右边是切换到 vercel 上部署的情况，看起来好了很多。
切到 vercel 重新部署，域名重新解析配置好之后，对于之前 github action 定时部署的情况，需要重新写一份 workflow job。
搜索vercel 同样支持 Deploy Hook 的方式。那就简单了，复制一份 Netlify 的文件，简单修改即可。
1、配置创建 Vercel Build Hooks
参考 Creating & Triggering Deploy Hooks 官方文档。
官方说的清清楚，部署钩子允许您创建接受 HTTP
POST请求的 URL，以触发部署并重新运行构建步骤。这些 URL 与您的项目、存储库和分支唯一链接，因此无需使用任何身份验证机制或向请求提供任何有效负载POST。此功能允许您将 Vercel 部署与其他系统集成。例如，您可以设置：
- 来自 Headless CMS 的内容更改的自动部署
- 通过配置第三方 cron 作业服务来触发 Deploy Hook 来进行计划部署
- 通过命令行强制部署
在vercel 项目设置→Git中找到 Deploy Hooks 创建的地方，输入 hooks 名字，和代码分支，即可创建。
2、创建 GitHub Actions secrets and variables
在Github 的项目Setting下设置 github actions 所需要的变量。
例如，创建VECEL_BUILD_HOOK变量，value 为上一步获得的 vecel build hook 地址。
3、实现 GitHub Actions
触发 hooks 的示例请求为：
响应示例：
发送请求后，您可以在项目仪表板上看到它触发了部署。
那么，实现 github actions 代码就比较简单了，参考如下：
参考资料
最近编写了一个项目，需要每天定时从 producthunt 抓取数据并生成阅读良好的 markdown 文档，项目已经上线，
参考地址。除此之外，还希望能够输入日期，手动触发抓取这一天的数据。
也就是，工作流有输入。当工作流由 cron 触发时，我需要它使用一些默认变量运行。当手动触发时，我想允许用户覆盖一些默认值。
Github Actions 工作流示例
比如：有如下 github actions 工作流：
每隔一段时间，输出一段文字
Periodically printing passages如果手动触发时，允许输入参数覆盖这一段文字，可以在定义工作流中，使用 inputs 来定义可以接收的输入，参考如下：
我可以在 GitHub 中的 Actions 标签中触发此操作：
让这个工作发挥作用的关键是：
echo "MESSAGE=${{ github.event.inputs.text_to_print || env.DEFAULT_MESSAGE }}" >> $GITHUB_ENV上面一行选择将定义的变量赋值给变量，
MESSAGE然后将其注入到变量中$GITHUB_ENV。我们可以在Print some text步骤中引用它。