0%

文章导读:

本文介绍了在 Next.js 14 (基于App Router) 中实现 i18n 国际化多语言功能,并考虑在真实的场景中,一步步优化将功能完善。通过阅读完本文,你将立即掌握如何在 Next.js 中实现 i18n。

hero

前言

在互联网世界越来越扁平化的时代,产品的多语言显得越来越重要。幸运的在 Next.js 中通过简单的配置和代码即可快速支持多语言。但是,当我们在互联网上搜索 Next.js 如何支持多语言时,可能会看到各种实现方式、鱼龙混杂和奇技淫巧的方案,于是我们一头雾水,不禁怀疑人生:到底哪里出了问题?

今天,让我们从 0 到 1 在 Next.js 中实现一个多语言,揭开多语言的神秘面纱。

我们查看 Next.js 官方文档中的 i18n 介绍, https://nextjs.org/docs/app/building-your-application/routing/internationalization,比较清晰详细了,本文也将基于此篇文档制作。

开始之前,先看看最终运行效果:https://next-i18n-demo-two.vercel.app/

准备工作

首先,我们初始化一个 Next.js app,

1
npx create-next-app@latest

请注意选择 App Router,此处我使用的是 TypeScript

1
2
3
4
5
6
7
8
❯ npx create-next-app@latest
✔ What is your project named? … `next-i18n-demo`
✔ Would you like to use TypeScript? … No / `Yes`
✔ Would you like to use ESLint? … No / `Yes`
✔ Would you like to use Tailwind CSS? … No / `Yes
✔ Would you like to use `src/` directory? … No / `Yes`
✔ Would you like to use App Router? (recommended) … No / `Yes`
✔ Would you like to customize the default import alias (@/*)? … `No` / Yes

本地启动,

1
npm run dev

打开 http://localhost:3000 看到程序运行正常。

国际化介绍

在正式开始之前,我们先简单介绍一下国际化,国际化 internationalization,简称 i18n,也即在产品中支持多国语言文化和环境风俗,主要包括语言/时间/货币符号等。这篇文章中将只专注于语言部分。

在国际化的具体呈现上,常见的方式是网站默认进入某个语言的官网(通常是英文),并支持选择语言或地区,进行切换网站的不同语言版本。

具体实现方式上,有的网站以语言简称为前缀,如 en.wikipedia.org, zh.wikipedia.org;有的网站以语言简称作为路径后缀,如 aws.amazon.com/cnaws.amazon.com/jp,也有以国家地区域名为区分的,如以前的 apple.cn, apple.jp

其中诸如 en, zh, cn, jp ,也即语言编码,在不同版本的语言编码版本中略有不同,具体可参考文章下方参考资料。

在本文案例中,将以 ISO_3166 中的 enzh 编码分别代表英文和中文。

开始配置多语言

项目之前的文件结构:

1
2
3
4
5
6
7
8
9
10
11
12
├── package.json
├── public
│   ├── next.svg
│   └── vercel.svg
├── src
│   └── app
│   ├── favicon.ico
│   ├── globals.css
│   ├── layout.tsx
│   └── page.tsx
├── tailwind.config.ts
└── tsconfig.json

我们在 app 目录新建一个文件夹 [lang],然后将 app 目录的 laytout.tsxpage.tsx 移入 [locales]中,

移动后的文件结构如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
├── package.json
├── postcss.config.mjs
├── public
│   ├── next.svg
│   └── vercel.svg
├── src
│   └── app
│   ├── [lang]
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── favicon.ico
│   └── globals.css
├── tailwind.config.ts
└── tsconfig.json

Tips:

注意同步修改 layout.tsx 中 globals.css 的引用位置。

接下来,我们定义不同语言的 json 资源文件,你可以放入你习惯的文件目录,我这里放入 public/dictionaries,格式如下:

en.json

1
2
3
4
5
6
7
8
9
10
{
"page": {
"title": "Next.js i18n Demo",
"desc": "How to implement i18n with Next.js (based on App Router)"
},
"home": {
"title": "Hello, Next.js i18n",
"desc": "This is a demo of Next.js i18n"
}
}

zh.json

1
2
3
4
5
6
7
8
9
10
{
"page": {
"title": "Next.js i18n 示例",
"desc": "搞懂 Next.js 实现 i18n 国际化多语言(基于App Router)"
},
"home": {
"title": "你好, Next.js i18n",
"desc": "这是一个 Next.js i18n 示例"
}
}

紧接着,我们创建一个文件,用于加载多语言资源文件并获取相应语言文本。

app/[lang] 目录添加 dictionaries.js,注意检查文件目录及文件名是正确并匹配的。

1
2
3
4
5
6
7
8
import 'server-only'

const dictionaries = {
en: () => import('./dictionaries/en.json').then((module) => module.default),
zh: () => import('./dictionaries/zh.json').then((module) => module.default),
}

export const getDictionary = async (locale) => dictionaries[locale]()

使用多语言

我们在 pages.tsx 页面中使用多语言功能。

首先,为函数增加 lang 参数,注意为函数添加 async 关键字,

1
2
3
export default async function Home({ params: { lang } }: { params: { lang: string } }) {
...
}

添加多语言的调用,

1
const t = await getDictionary(lang);

在页面上使用,为了方便我将 page.tsx 上默认的代码进行清理,只保留文本展示。

1
2
3
4
5
6
<main className="flex min-h-screen flex-col items-center justify-between p-24">
<p className="fixed left-0 top-0 flex w-full justify-center border-b border-gray-300 bg-gradient-to-b from-zinc-200 pb-6 pt-8 backdrop-blur-2xl dark:border-neutral-800 dark:bg-zinc-800/30 dark:from-inherit lg:static lg:w-auto lg:rounded-xl lg:border lg:bg-gray-200 lg:p-4 lg:dark:bg-zinc-800/30">
{t.home.title}
</p>
{t.home.desc}
</main>

重启程序或等程序热更新成功,分别打开不同语言的页面 http://localhost:3000/en http://localhost:3000/zh 即可看到效果。

设置默认语言

看起来不错,但是细心的朋友会发现打开 http://localhost:3000 会出现 404 error。为了解决这个问题,我们需要在未选择语言时,默认设置一个语言。

为此,我们可以在 src 目录创建一个 middleware.ts ,然后复制文档中的代码。

核心逻辑很简单:

判断 URL 的 pathname 中是否含有某个语言标识,如果有则直接返回,否则在获取合适的语言后,将 URL 重定向为 /${locale}${pathname}

重点在 getLocale 函数中,我们需要指定合适的语言。在此处,我们先简单处理:使用默认的 defaultLocale = "en"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
import { NextRequest, NextResponse } from "next/server";

let locales = ["en", "zh"];
let defaultLocale = "en";

// Get the preferred locale, similar to the above or using a library
function getLocale(request: NextRequest) {
return defaultLocale;
}

export function middleware(request: NextRequest) {
// Check if there is any supported locale in the pathname
const { pathname } = request.nextUrl;
const pathnameHasLocale = locales.some(
(locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
);

if (pathnameHasLocale) return;

// Redirect if there is no locale
const locale = getLocale(request);
request.nextUrl.pathname = `/${locale}${pathname}`;
// e.g. incoming request is /products
// The new URL is now /en-US/products
return NextResponse.redirect(request.nextUrl);
}

export const config = {
matcher: [
// Skip all internal paths (_next)
"/((?!_next).*)",
// Optional: only run on root (/) URL
// '/'
],
};

程序更新后,我们打开 http://localhost:3000/ 可以看到会自动跳转到设置的默认语言页面。

获取默认语言的优化

在上一节获取默认语言时,我们简单处理为 defaultLocale = "en" ,更优雅的方式是:根据用户的系统或者浏览器的语言来设置默认语言

我们可以通过获取浏览器 HTTP headers 中的 Accept-Language 字段来达到目的。它的数据格式大致如下:

1
2
3
4
英文时:
accept-language: en-US,en;q=0.5
中文时:
accept-language: zh-CN,zh-Hans;q=0.9

我们将 middleware 改造如下:

  1. 从 HTTP headers 中获取 Accept-Language,如果为空则返回默认语言
  2. 解析 Accept-Language 中的语言列表,并根据配置的语言列表,匹配获取对应的语言(如果没有则返回默认语言)

安装依赖 @formatjs/intl-localematcher, negotiator, @types/negotiator,并实现如下逻辑:

1
2
3
4
5
6
7
function getLocale(request: NextRequest) {
const acceptLang = request.headers.get("Accept-Language");
if (!acceptLang) return defaultLocale;
const headers = { "accept-language": acceptLang };
const languages = new Negotiator({ headers }).languages();
return match(languages, locales, defaultLocale);
}

通过修改系统的语言,打开 http://localhost:3000 会自动跳转到同系统语言一致的页面,测试成功。

多语言的其它处理

存储用户网页语言

更进一步地,我们可以在 Cookie 中存储用户网页中的语言,并在下次访问时使用:

1
2
3
4
5
6
7
// 获取Cookie 
if (request.cookies.has(cookieName)) {
return request.cookies.get(cookieName)!.value;
}

// 设置 Cookie
response.cookies.set(cookieName, locale);

网页标题描述等的多语言处理

在网页 metadata 中使用多语言时,page.tsx添加如下代码:

1
2
3
4
5
6
7
export async function generateMetadata({ params: { lang } } : { params: { lang: string } }) {
const t = await getDictionary(lang);
return {
title: t.page.title,
description: t.page.desc,
};
}

SSG 的多语言处理

在处理静态站点(SSG)中使用多语言时,layout.tsx代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
interface LangParams {
lang: string;
}

export async function generateStaticParams() {
return [{ lang: "en" }, { lang: "zh" }];
}

export default function RootLayout({
children,
params,
}: Readonly<{
children: React.ReactNode;
params: LangParams;
}>) {
return (
<html lang={params.lang}>
<body className={inter.className}>{children}</body>
</html>
);
}

切换多语言(语言选择器或链接)

可根据实际情况添加语言选择器(下拉框)或不同的链接,从而跳转到对应语言的页面。

例如通过链接实现多语言切换:

1
2
3
4
5
<div className="space-x-2">
<Link href="/en">English</Link>
<span>|</span>
<Link href="/zh">Chinese</Link>
</div>

尾声

通过上述步骤的学习,我们初步熟悉并实践了在 Next.js 中使用多语言。千里之行,始于足下,国际化的工作不止于此,我们当然也还有尚未完善的地方,就留给屏幕前的你吧。

最后附上 middleware.ts 完整代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
import Negotiator from "negotiator";
import { match } from "@formatjs/intl-localematcher";
import { NextRequest, NextResponse } from "next/server";

const locales = ["en", "zh"];
const defaultLocale = "zh";
const cookieName = "i18nlang";

// Get the preferred locale, similar to the above or using a library
function getLocale(request: NextRequest): string {
// Get locale from cookie
if (request.cookies.has(cookieName))
return request.cookies.get(cookieName)!.value;
// Get accept language from HTTP headers
const acceptLang = request.headers.get("Accept-Language");
if (!acceptLang) return defaultLocale;
// Get match locale
const headers = { "accept-language": acceptLang };
const languages = new Negotiator({ headers }).languages();
return match(languages, locales, defaultLocale);
}

export function middleware(request: NextRequest) {
if (request.nextUrl.pathname.startsWith("/_next")) return NextResponse.next();

// Check if there is any supported locale in the pathname
const { pathname } = request.nextUrl;
const pathnameHasLocale = locales.some(
(locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
);

if (pathnameHasLocale) return;

// Redirect if there is no locale
const locale = getLocale(request);
request.nextUrl.pathname = `/${locale}${pathname}`;
// e.g. incoming request is /products
// The new URL is now /en-US/products
const response = NextResponse.redirect(request.nextUrl);
// Set locale to cookie
response.cookies.set(cookieName, locale);
return response;
}

export const config = {
matcher: [
// Skip all internal paths (_next)
"/((?!_next).*)",
// Optional: only run on root (/) URL
// '/'
],
};

完整代码可在 https://github.com/xumeng/next-i18n-demo 获取。

最终运行效果:https://next-i18n-demo-two.vercel.app/


参考资料:

https://nextjs.org/docs/app/building-your-application/routing/internationalization

https://en.wikipedia.org/wiki/ISO_3166

https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes

https://en.wikipedia.org/wiki/IETF_language_tag

https://www.alchemysoftware.com/livedocs/ezscript/Topics/Catalyst/Language.htm

拖着行李箱的人们,

满载着一年的劳累,

穿过长长的铁道,

回到母亲怀内,

妈妈

我想再睡会

2024.2.7 腊月二十八


My personal server uses CentOS 7.9, and there are often strange errors when deploying some AI applications.
For example, recently, an error was reported when deploying an application:

1
/lib64/libstdc++.so.6: version GLIBCXX_3.4.xx not found

Online search for solutions, there are different opinions, either reinstall gcc, or recompile and install libstdc++,export LD_LIBRARY_PATH and so on.
Several attempts have failed, and there is no way to upgrade the os version. Finally, a suitable solution is found, and it’s worked for me.

  1. Find and display all packages that provide libstdc++.so.6 as a library file through yum
1
sudo yum provides libstdc++.so.6
  1. Download new version libstdc.so.

NOTICE: Since I need version 3.4.22+, so I can just update it to 3.4.26. Other versions are the same.

1
2
3
cd /usr/local/lib64
sudo wget http://www.vuln.cn/wp-content/uploads/2019/08/libstdc.so_.6.0.26.zip
unzip libstdc.so_.6.0.26.zip
  1. Copy libstdc++.so.6.0.26 to /usr/lib64
1
2
cp libstdc++.so.6.0.26 /usr/lib64
cd /usr/lib64
  1. Check the soft link version of libstdc++.so.6,
1
ls -l | grep libstdc++

It may shows like this:

1
libstdc++.so.6 ->libstdc++.so.6.0.19
  1. Remove /usr/lib64 original link libstdc++.so.6, you can backup it before remove.
1
sudo rm libstdc++.so.6

then, relink it.

1
sudo ln -s libstdc++.so.6.0.26 libstdc++.so.6
  1. OK, check the newest link
1
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

It may shows like this:

1
2
3
4
5
GLIBCXX_3.4
...
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_DEBUG_MESSAGE_LENGTH

Well Done!


In my Hexo blog, when I include special symbols inside the title in posts, it reports this error:

1
2
3
ERROR Process failed: _posts/en/XXX.md
YAMLException: incomplete explicit mapping pair; a key node is missed; or followed by a non-tabulated empty line at line 1, column 54:
... for Backend System Refactoring\: How to do backend system refac ...

Solution:
Include the title in single quotes, like:

1
2
3
title: 'How to read a book'
lang: en
date: 2023-01-01

coverimg

Introduction

As the company’s business experiences explosive growth, both the scale of requirements and the user base are rapidly expanding. This presents challenges to the system in terms of the three high (high performance, high concurrency, high availability), scalability, and maintainability. The old system, due to various limitations in its early design (such as the expertise of early participants, the foresight of architectural design, impatience of management, etc.), gradually becomes inadequate to meet current and future demands, exposing various issues. Developers find themselves dragging an old, worn-out car on the highway, which is a daunting task. In simpler terms, the codebase of the old system has become too problematic to fix, leading to a situation where developers either get buried in its issues or abandon the project altogether.

At this point, a common question arises: should we continue trying to patch the issues, or should we choose to refactor? Patching is simply not feasible, not in this lifetime. Refactoring, on the other hand, requires the courage of a true hero because it’s a complex and time-consuming task. Moreover, it can impact ongoing business development or even bring it to a standstill. Often, product managers and executives are not supportive because they only care about one thing: when will the next feature be ready? Everything else is your development team’s problem.

If you choose the path of refactoring, you must be prepared to see it through, no matter what. How can you ensure a successful refactoring from the get-go? Based on common practices in internet projects and my personal experience in refactoring projects, here is an outline of the common steps for refactoring systems of various sizes:

Step 0: Convincing Stakeholders

Refactoring is not just the responsibility of the development team; it’s a collective effort involving the entire project team. Refactoring can improve the system’s performance, availability, and scalability, as well as optimize and streamline business processes to meet new demands. It requires a significant investment of resources and must have the support of stakeholders. Typically, this requires explaining the benefits and drawbacks of refactoring, as well as the critical issues that would arise if refactoring is not done. Once you have their support, the refactoring work can officially begin.

Participants: Technical Leader

Step 1: Establish Clear Refactoring Goals

Refactoring is a long-term endeavor; it’s not something that can be completed in one or two iterations, or even within a few months. It requires a substantial investment of manpower, resources, time, and effort. So, what are our goals in this prolonged battle? Are we aiming to meet the system’s high-performance requirements through a more efficient architecture? Or do we want to enhance code quality through refactoring? Perhaps we aim to introduce new technologies and frameworks to upgrade the entire system or optimize business processes to address previously unmet requirements. Once you have clear goals, you can work purposefully.

Participants: Technical Leader, Architect

Step 2: Define the Scope of Refactoring and Make Predictions

Refactoring typically falls into several levels:

  • Platform-level refactoring: Refactoring the entire platform, such as Alibaba transitioning from the LAMP stack to the Java platform.
  • System-level refactoring: Refactoring specific business systems, such as introducing microservices or SOA architecture to break down monolithic applications.
  • Architecture-level refactoring: Improving the existing architecture through adjustments and redesign, addressing architectural shortcomings, like decoupling business logic through layered design or introducing caching for improved concurrency.
  • Business-level refactoring: Addressing specific business requirements that cannot be met due to the limitations of the current system, often involving the refactoring of business processes or database structures.
  • Module/code-level refactoring: The most common form of refactoring, typically involving the use of design patterns, encapsulation, and code optimization to improve code structure and performance.

Determine the level of refactoring required, the overall scope, and the technology stack for refactoring. Then, conduct a scientific assessment and estimation of the refactoring work. This includes identifying the costs, required resources, and time commitments, as well as assessing whether ongoing business requirements can be accommodated during the refactoring process. Once these predictions are established, you can provide stakeholders with a clear understanding, especially when they ask when new requirements can be delivered.

Participants: Technical Leader, Architect, Developers

Step 3: Familiarize Yourself with the Old System and Document Business Processes

Refactoring is not about abandoning the old system; it’s about continuously working with it. Knowing your enemy is the key to victory. Refactoring not only requires a clear understanding of the new system’s goals and future, but also a deep familiarity with the old system, especially its pitfalls. At this stage, the participants in the refactoring project, especially those who worked on the old system, should document and organize information related to the old system’s business and technical details. This includes collecting documents such as design documents, technical documents, architecture diagrams, UML diagrams, and ER diagrams related to the system.

The following are common preparation tasks before refactoring the old system:

  • Gathering information and documentation related to the old system, including design documents, technical documents, architectural diagrams, UML diagrams, ER diagrams, and other graphical materials.
  • Mapping and documenting business lines and processes, outlining projects and business flows, and documenting them.
  • Reviewing key code and database designs in the old system.

Any issues or uncertainties should be addressed promptly through communication with relevant personnel from the business side, ensuring that problems are resolved early in the process.

Participants: Technical Leader, Architect, Developers

Step 4: Database Refactoring

If the refactoring involves changes to the database, database refactoring is typically the first step. Many refactoring initiatives are triggered by issues related to the database. During database refactoring, the deficiencies and obstacles in the old system’s database design are addressed. This may involve redesigning tables using normalization or denormalization techniques, considering sharding or partitioning strategies, and more.

Participants: DBA, Architect

Step 5: Backend System Refactoring

Before starting the backend system refactoring, it’s essential to have design and technical documentation in place, as mentioned earlier. Once these documents are finalized through discussions and planning, the architect can proceed with system architecture design, and backend developers can begin coding. This phase is often the most time-consuming and critical part of the refactoring process. The quality of the backend architecture directly affects the success of the refactoring, the quality of the business code, and the overall refactoring quality.

Due to the extended timeline of this phase and the fact that its results may not be immediately visible, Agile development methodologies are often used. This allows for iterative development, ensuring effective planning and continuous progress. The advantages of using iterations include:

  1. Effective planning and quantification of the entire refactoring process.
  2. Visible achievements at each stage, preventing the team from getting stuck in a long refactoring process.
  3. The ability to test or observe refactored parts promptly during iterations, allowing continuous learning and improvement.

During backend system refactoring, it’s essential to have clear, quantifiable goals and standards. For example, defining the QPS (Queries Per Second) supported by various systems and business modules, the expected response times for interfaces, etc. This enables the team to focus on achieving these goals during refactoring.

Regular code reviews should also be conducted throughout the refactoring process to identify and address issues with the refactoring itself and the quality of the code. This helps prevent the introduction of poor designs or subpar code that could harm the entire system.

Participants: Technical Leader, Architect, Developers

Step 6: Data Migration and Verification

If database refactoring is part of the project, data migration becomes a crucial step. It generally involves two types of migration: full migration and incremental migration. Full migration transfers all data from the old system to the new one in one go, while incremental migration handles data created in the old system after full migration until the old system is retired. These migrations are typically scripted or programmed to avoid manual errors.

After migration, it’s essential to compare the data between the old and new systems. This comparison can also be automated through scripts or programs to identify discrepancies and perform any necessary adjustments or investigations.

Participants: DBA, Developers

Step 7: System Validation, Integration, and Testing

As the backend system refactoring progresses, scripts and programs should be developed to validate the business interfaces between the old and new systems. This ensures that issues in the refactoring process are detected promptly, and, if necessary, architectural and database adjustments can be made. Additionally, increasing unit test coverage during refactoring is highly beneficial.

Once the dependencies between systems and modules are resolved, integration testing can begin. Comprehensive testing, including functional testing, stability testing, performance testing, local testing, and simulating production environments, should be performed. Any issues identified during testing should be addressed, verified, and fixed to meet the standards required for a smooth release.

Participants: Architect, Developers, Testers

Step 8: Gradual Deployment and Monitoring

When the backend system refactoring reaches a certain level of stability, it’s time to initiate gradual deployment. During this phase, only a portion of the traffic is directed to the new system. This allows for real-time tracking and analysis of logs and monitoring alarms. Any issues or anomalies can be addressed promptly. As confidence in the new system’s stability grows, the scope and volume of the deployment can be gradually increased. Continuous monitoring of logs and alarms should be maintained throughout this phase.

Participants: DevOps Team, Testers, Developers

Step 9: System Transition

When it comes to transitioning to the new system, it’s crucial to have a well-defined transition plan in place. This plan should include detailed processes, workflows, and contingency plans, including rollback procedures in case unexpected issues arise. This step ensures that the transition is smooth and minimizes disruption to the business.

Participants: DevOps Team, Testers

Conclusion

After completing the above steps, the system has undergone successful refactoring. However, it’s essential to understand that refactoring is a substantial undertaking, and even after the process, the system may not be flawless. Refactoring is not the endpoint but rather a new beginning.

里面,

取号,
排队,
叫号,
付费。

一切为了活着。


外面,

工作,
生活,
享乐,
受罪。

活着为了一切。

早高峰的洪流中,
我被人群簇拥着,
仿佛生命之王。

我感觉自己,
活着。
但又感觉,
死了。

ChatGPT辅助创作


There are multiple Git libraries are used on my machine, such as GitHub/Company Private Git repo, etc., the Git tool mainly uses Terminal and GitKraken, and occasionally strange issues will arise. For example, the following error occurred when deploying the Hexo Blog a few days ago:

1
2
3
4
5
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The usual solution is to regenerate the SSH Key of GitHub.

But there’s no issue with my local configuration, I can push code normally in Terminal and GitKraken.

Guessing that there might be some hitch in the process, I used:

1
ssh -T git@github.com

And saw:

1
Hi {username}! You've successfully authenticated, but GitHub does not provide shell access.

Then redeployed and pushed, It’s worked!

Reference:

https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey


机器上使用了多个 Git 库,比如 GitHub/公司 Git 库等,Git 工具主要使用 Terminal 和 GitKraken,偶尔会出现奇怪的问题。比如前两天在部署 Hexo Blog 时,遇到以下报错:

1
2
3
4
5
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

通常的解决方案是重新生成 GitHub 的 SSH Key。

但是我本地的配置是没问题的,可以在 Terminal 和GitKraken正常提交代码。

猜想可能是哪个环节不通,于是使用:

1
ssh -T git@github.com

看到:

1
Hi {username}! You've successfully authenticated, but GitHub does not provide shell access.

再重新部署提交,搞定!

参考:

https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey

任务堆积如山,
债务堆积如山,
茫茫一片看不见。

我,
堆积如山。