Next.js 如何在客户端导航时获取上一页(referer)

想给之前上线的工具站做个博客数据统计: blogs。

理所当然用到了document.referer，最方便的获取上一个页面的方式，结果发现获取到的都是第一次 load 的页面，而不是导航前的那个页面。

为什么会这样？

Next.js 在生产环境中默认采用前端导航（Client-side Navigation）的方式。这意味着页面加载完之后，在网站内部点击链接时，浏览器并不会执行一次完整的页面刷新。相反，Next.js 会在客户端通过 JavaScript 异步加载新页面的数据和组件，然后更新 DOM。

这种类似 单页应用（SPA） 的行为导致了一个关键问题：
document.referrer 的值在页面首次加载后保持不变。当通过内部链接从blog/zh/1导航到 blog/zh/post/[slug] 时，由于没有发生完整的页面重载，document.referrer 的值仍然会是最初访问网站的那个值，而不是blog/zh/1。

Read More

Next.js RSC _rsc参数丢失的那些坑以及解决方案

最近在用 Next.js 的 RSC（React Server Component）时遇到了一个比较隐晦的问题，记录一下踩坑过程和应对方案。

如果你在项目里既使用了 CDN（并且缓存了 html），又使用了middleware的重定向（middleware 会处理 rsc 请求），又用了 RSC 特性（开启了 prefetch 等情况），如果你发现部分页面 html 变成了一大串“乱码”（其实是 rsc 请求的返回结果），可以仔细看看。

RSC 请求是怎么工作的？

Next.js 在请求 RSC 和 HTML 页面时，路径和方法其实是一样的，唯一的区别在于它会带上一个 _rsc 的参数和一些特定 header。

比如你访问页面 /about：

  • HTML 请求：
    GET /about
  • RSC 请求：
    GET /about?_rsc=<随机字符串> 以及特定的 header

这里的 _rsc 参数是 Next.js 内部用来标识“这是一次 RSC 请求”，header 里也有类似 Next-Router-State-Tree, rsc 等用于数据请求和分割的内容。

Read More

[翻译]我如何使用 Claude Code

原文出处: https://spiess.dev/blog/how-i-use-claude-code

一个月前，我订阅了 Claude Max。在此之前，我已经使用包括 Claude Code 在内的 AI 代理一段时间了，但随着统一价格的推出，我的使用量猛增，它已成为我许多任务的日常驱动力。我发现自己现在去 VS Code 的次数少了很多。

由于 AI 代理目前对每个人来说都是新事物，我想分享一些我最近注意到模式可能会很有趣。以下是我如何使用 Claude code。

开始新对话 (Start New Threads)

如果说我希望你从这篇文章中学到一件事，那就是你应该更频繁地调用 /clear。

AI 代理往往随着对话时间的延长而变得更不可预测。当你提出不同问题时尤其如此。我发现即使这意味着重复一些指令，创建一个新的提示通常会更有效。

一旦我开始更积极地这样做，我的结果就显著改善了。而且我绝对不是唯一一个提出这个建议的人。

Read More

Next.js使用auth.js+dirzzle+postgresql报错分析

在自己的测试项目里想着做登录功能，看到authjs就接到项目里去，本身就使用的drizzle，在不配置 db adapter 的情况下运行正常，但只要配置就会报错:

1
2
3
4
5
6
7
8
⨯ Error [TypeError]: Cannot read properties of undefined (reading 'reduce')
   at <unknown> (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:709:27)
   at runModuleExecutionHooks (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:755:9)
   at instantiateModule (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:707:9)
   at getOrInstantiateModuleFromParent (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:640:12)
   at esmImport (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:143:20)
   at [project]/src/db/db.ts [middleware-edge] (ecmascript) (.next\server\edge\chunks\[root of the server]__a687996d._.js:28:218)
   at <unknown> (.next\server\edge\chunks\edge-wrapper_c7ecd8c0.js:709:27)

无法启动

Read More

显卡的TOPS AI算力比较

虽然自己没设备但喜欢聊 😀，和别人讨论的时候经常要反复查，查询一下汇总，有可能填错了。。。到时候发现错误再订正吧。

AMD 的没找到哪个表/文档里有算 TOPS 的…就不列了

N 卡

20 系到 40 系

GeForce RTX 20 系列

型号 架构 制程 (nm) 显存大小 显存类型 显存位宽 显存带宽 (GB/s) 峰值单精度 (FP32) TOPS (AI) TDP (W)
RTX 2080 Ti Turing 12 11GB GDDR6 352-bit 616 13.45 TFLOPS 114 TOPS 260
RTX 2080 Super Turing 12 8GB GDDR6 256-bit 496 11.15 TFLOPS 89 TOPS 250
RTX 2080 Turing 12 8GB GDDR6 256-bit 448 10.07 TFLOPS 81 TOPS 225
RTX 2070 Super Turing 12 8GB GDDR6 256-bit 448 9.06 TFLOPS 72 TOPS 215
RTX 2070 Turing 12 8GB GDDR6 256-bit 448 7.47 TFLOPS 65 TOPS 175
RTX 2060 Super Turing 12 8GB GDDR6 256-bit 448 7.19 TFLOPS 57 TOPS 175
RTX 2060 Turing 12 6GB GDDR6 192-bit 336 6.45 TFLOPS 52 TOPS 160

Read More

Jina ReaderLM v2 测试记录

jina 出了 ReaderLM v2 版本，这个版本的 ReaderLM 在处理文本数据时更加高效和准确。
之前简单测试了下 v1, 结论是:

  • 幻觉严重, 尤其特别喜欢造 url
  • 很容易触发无限生成 比如 example1 example2…. 一直生成下去

第一眼就是不可用就没继续了。
这次 v2 来了，测试了一下，幻觉问题好了很多，无限生成测试了几个也没遇到，但最为一个 html 转 markdown 的工具还是不够稳定。
这里的稳定性主要是指，与传统的基于语法树解析的工具相比，它在处理速度和结构识别的准确性上还有差距。他的确能生成不错的 markdown，但是很容易被正确结构但是内容文本里有特殊构造的/或者有一些语法错误的 html 页面所影响。

注意：这个博客里的测试只是为了列出 v2 的一些问题，针对问题进行特殊构造的测试，实际网页可能也遇不到文中提到的问题，具体以实际场景为准了。
顺道一提，这个模型是以 CC 协议发布的，所以商用场景需要遵守相关协议。

Read More

聊一聊AWS Route 53的托管区

AWS 坑爹啊

最近查看 AWS 的账单才发现，在 route53 买的每个域名每个月都会额外收 0.5 刀，并且还有解析费，一看是因为用了托管区（hosted zone）,这个收费是托管区的。

这个托管区的作用其实就是 DNS 管理，emmmmm….那可不得不迁移到赛博大善人 Cloudflare 了。

这里记录一些遇到的问题吧，并把一些概念阐述下。

Read More

在remix中谨慎使用useFetcher进行poll

问题概述

今天在开发时遇到了一个有趣的问题。我在实现一个异步任务提交和状态轮询的功能时，使用了两个 useFetcher：

  • 第一个 fetcher 用于任务提交，使用 submit 方法（这样可以触发页面 credit 的自动刷新）
  • 第二个 fetcher 用于状态轮询，使用 load 方法（因为不需要页面刷新数据）

结果发现了一个奇怪的现象：第一个任务能正常工作，但提交第二个任务后，轮询返回的却始终是第一个任务的数据, 后面也是返回的永远是第一个任务的结果.

Read More

Spring Boot Docker优雅关机总结

1. 问题背景

在 Docker 环境中运行 Spring Boot 应用时，为了确保应用能够优雅关机（Graceful Shutdown），需要正确配置多个组件。错误的配置可能导致应用无法正常接收关闭信号，从而无法执行优雅关机流程。

今天才发现服务器上配置有问题没支持, 本地是没问题的。。。最后发现是配置有问题, 这里总结一下。

日志中出现INFO o.s.b.w.e.tomcat.GracefulShutdown - Commencing graceful shutdown. Waiting for active requests to complete表示成功(我使用的是 tomcat 容器, 其他的日志内容可能不太一样)。

2. Docker 关机流程

Docker 容器的关闭过程如下：

  1. Docker 向容器的 1 号进程（PID 1）发送 SIGTERM 信号
  2. 等待 stop_grace_period 时间（默认 10 秒）
  3. 如果进程还未退出，发送 SIGKILL 信号强制终止

3. 常见配置错误

Read More