GatsbyJS页级查询能否使用页面URL查询参数作为入参

核心运行逻辑 #

Gatsby 的页级查询（即你在页面组件顶层导出的、用graphql模板字符串定义的查询）是构建阶段执行的逻辑：在静态资源生成完成、用户实际访问页面前，这部分查询的所有变量、返回结果就已经被编译进最终的静态HTML/JS包中。

• 构建阶段不存在“用户实际访问时的URL地址”这个概念，自然不可能直接把URL上的动态查询参数（比如?slug=xxx）自动抓取出来，作为页级查询的$slug变量传入。
• 目前Gatsby 原生支持的、唯一能给页级查询传入自定义变量的路径，就是创建页面时通过页面上下文（page context）赋值：当你调用createPage方法生成路由时，传入的context对象里的所有字段，会被自动映射为页级GraphQL查询的可用变量，和你示例里的$slug一一对应。

基于URL查询参数取数的可行替代方案 #

如果你确实需要依赖浏览器端拿到的URL查询参数做数据匹配，不能把这部分逻辑绑定到构建期的页级查询上，需要更换实现路径：

• 方案1：采用客户端运行时查询。在页面组件的React生命周期钩子里（比如useEffect）读取当前window.location上的查询参数，手动发送请求调取Gatsby生成的内置GraphQL端点，把读到的参数值作为查询变量传入，拿到对应数据后再渲染页面。这个过程在用户浏览器端执行，完全可以动态获取URL上的参数值，但要注意这种方式失去了构建期静态预渲染的性能优势，需要额外处理首屏加载的状态提示。
• 方案2：提前枚举所有可能的查询参数取值。如果你的URL查询参数取值范围是固定、可提前遍历的（比如博客站所有文章的slug都是可枚举的），可以在gatsby-node.js的构建流程里，对每个可能的参数值单独调用一次createPage方法，把对应的slug值塞进页面上下文，让Gatsby为每个参数组合生成独立的静态页面。这种方式本质上还是走页面上下文传参的逻辑，只是把URL参数的取值提前融入了构建流程。

常见认知误区：不要把路径形式的动态参数（比如路由定义里的/:slug）和查询参数搞混。即使是路径形式的动态参数，只要和页级静态查询绑定，也必须在构建阶段把参数值提前放进页面上下文，不存在运行时自动从URL抓取参数喂给构建期查询的机制。

内容的提问来源于stack exchange，提问作者noi.m