CodeXun

如何查看Google账号地区以及如何更改Google账号地区

Mon, 25 Aug 2025 00:00:00 GMT

之前写过一篇 如何切换 google play 账号到美区，锁定美区实现ChatGPT应用无障碍下载** **介绍了如何切换 gp 账号到美区，突破一些 app 的下载限制。

其实除了 gp 账号的地区限制之外，google 本身账号也有地区属性，并且可以和Google Play 账号的地区不一致。

例如，你的 Google 账号可能是在香港地区创建的，但您可以将 Google Play 地区设置为美国。另外，Google账号地区不是一成不变的，可能随着你常用IP地址变动，Google账号地区也会随之变化。

如何查看Google账号地区

1.登录Google账号

2.点击服务条款或者直接登录网站：https://policies.google.com/terms

3.可以看到国家/地区版本：XX地区（如下图）

如何更改Google账号地区

Google账号所属的国家或地区不是一成不变的，开始是某个地区的，等你长期用某地的IP登录后，被系统检测到，系统会自动帮你更改成该地区的Google账号。

当然，短时间内想快速修改账号地区的话，可以按照如下操作步骤，自行修改Google账号所属的国家或地区。

1、用希望修改的国家或地区IP登录Google账号，最好是用该IP连续登录一周左右。 2、修改路径在常见问题解答页面，也可以用登录的账号直接打开网站：https://policies.google.com/country-association-form 按下图填写提交即可。

3、填写要求改目的的地区，最好和你科学上网的 ip 地址匹配，理由的话可以自己写的真诚一些。

4、大概2-3天后系统会给该邮箱告知申请的结果，可能会失败，也可能会成功。失败的原因大概是使用目标IP登录该Google账号时间过短。

为何要更改Google账号的地区

很多喜欢玩外服的游戏玩家都知道，Google是分国家地区或地区的，而Google比如谷歌礼品卡，有美国谷歌礼品卡、香港谷歌礼品卡，日本谷歌礼品卡，韩国谷歌礼品卡等。自从谷歌修锁区以来，导致很多游戏玩家不能成功兑换谷歌礼品卡。想要成功兑换礼品卡，必须要当地的谷歌账号和礼品卡以及IP。

另外，还有某些地区账号的地理套利，比如之前Google One如果采用土耳其邮箱，就可以很简单的就薅到土耳其Google One的低价羊毛，不知道怎么操作的小伙伴。

再比如YouTube Premium在个别国家的个人会员的价格，因为汇率的原因，可以做到远远低于美国地区的价格进行订阅。

	订阅费USD/月（当地货币）	差额USD/月	参考汇率汇率换算
美国	$13.99	–	–
尼日利亚	$0.86（1,100 NGN）	-$13.13	1 USD =1,285 NGN
阿根廷	$1.14(389[ARS])	-$12.85	$1=340.00[ARS]

Java中单例模式的几种实现方式总结

Wed, 20 Aug 2025 00:00:00 GMT

单例模式（Singleton Pattern）是Java中最基本和最常用的设计模式之一。该模式确保一个类只有一个实例，并提供一个全局访问点来访问该实例。在需要频繁创建和销G毁对象或者需要一个全局唯一的对象（例如，线程池、缓存、日志对象等）的场景下，单例模式尤为重要。

以下总结了Java中几种常见的单例模式实现方式，并分析了各自的优缺点。

1. 饿汉式（Eager Initialization）

饿汉式在类加载时就立即创建实例，因此是线程安全的。

public class EagerSingleton {
    private static final EagerSingleton INSTANCE = new EagerSingleton();

    private EagerSingleton() {}

    public static EagerSingleton getInstance() {
        return INSTANCE;
    }
}

优点:

实现简单，代码可读性高。
在类加载时就完成了实例化，避免了多线程同步问题，是线程安全的。

缺点:

在类加载时就创建实例，即使后续从未使用过该实例，也会占用内存空间，可能造成资源浪费。

2. 懒汉式（Lazy Initialization）

懒汉式在第一次调用getInstance()方法时才创建实例。

2.1 基础懒汉式（非线程安全）

public class LazySingleton {
    private static LazySingleton instance;

    private LazySingleton() {}

    public static LazySingleton getInstance() {
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

优点:

实现了懒加载，只有在需要时才创建实例，节约了资源。

缺点:

在多线程环境下是非线程安全的。如果多个线程同时进入if (instance == null)判断，并且此时instance都为null，那么将会有多个线程创建出多个实例，违背了单例模式的初衷。

2.2 线程安全的懒汉式（同步方法）

通过在getInstance()方法上添加synchronized关键字，可以保证线程安全。

public class SynchronizedLazySingleton {
    private static SynchronizedLazySingleton instance;

    private SynchronizedLazySingleton() {}

    public static synchronized SynchronizedLazySingleton getInstance() {
        if (instance == null) {
            instance = new SynchronizedLazySingleton();
        }
        return instance;
    }
}

优点:

解决了多线程环境下的线程安全问题。

缺点:

每次调用getInstance()方法时都需要进行同步，即使实例已经被创建。这会导致不必要的性能开销，尤其是在高并发场景下。

3. 双重检查锁定（Double-Checked Locking）

双重检查锁定是对线程安全的懒汉式的一种优化，旨在减少不必要的同步开销。

public class DoubleCheckedSingleton {
    private static volatile DoubleCheckedSingleton instance;

    private DoubleCheckedSingleton() {}

    public static DoubleCheckedSingleton getInstance() {
        if (instance == null) {
            synchronized (DoubleCheckedSingleton.class) {
                if (instance == null) {
                    instance = new DoubleCheckedSingleton();
                }
            }
        }
        return instance;
    }
}

关键点:

使用volatile关键字修饰instance变量，确保其可见性和禁止指令重排。
进行两次if (instance == null)检查，第一次检查是为了避免在实例已存在的情况下进入同步代码块，从而提高性能。第二次检查是为了在同步代码块内部再次确认实例是否被创建，防止多个线程同时通过第一次检查后重复创建实例。

优点:

兼顾了线程安全和懒加载的性能。只有在第一次创建实例时才会进入同步代码块，后续的调用将直接返回已创建的实例，性能较高。

缺点:

实现相对复杂，容易出错。volatile关键字是必不可少的，否则可能由于指令重排导致获取到未完全初始化的对象。

4. 【推荐】静态内部类（Static Inner Class）

这是目前被广泛推荐的一种实现方式，它利用了JVM类加载机制来保证线程安全和懒加载。

public class StaticInnerClassSingleton {
    private StaticInnerClassSingleton() {}

    private static class SingletonHolder {
        private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
    }

    public static StaticInnerClassSingleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

原理:

当StaticInnerClassSingleton类被加载时，其静态内部类SingletonHolder并不会被加载。
只有当第一次调用getInstance()方法时，JVM才会加载SingletonHolder类，并初始化INSTANCE。
JVM在加载类时是线程安全的，因此保证了只有一个线程可以初始化INSTANCE。

优点:

实现了懒加载。
由JVM保证线程安全，无需任何同步代码，性能高。
实现简单，代码清晰。

5. 枚举（Enum）

这是《Effective Java》作者Joshua Bloch推荐的最佳实现方式。

public enum EnumSingleton {
    INSTANCE;

    public void doSomething() {
        System.out.println("do something...");
    }
}

优点:

实现最简单。
天然线程安全。
能有效防止通过反射和反序列化创建新的对象，从而破坏单例。

缺点:

不具备懒加载的特性。

总结

实现方式	线程安全	懒加载	推荐指数	备注
饿汉式	是	否	⭐⭐⭐	实现简单，但可能造成资源浪费。
懒汉式（非线程安全）	否	是	⭐	仅限单线程环境使用。
懒汉式（同步方法）	是	是	⭐⭐	性能开销较大，不推荐。
双重检查锁定	是	是	⭐⭐⭐⭐	实现较复杂，需正确使用`volatile`。
静态内部类	是	是	⭐⭐⭐⭐⭐	兼具懒加载和线程安全，实现简单，推荐使用。
枚举	是	否	⭐⭐⭐⭐⭐	最简洁、最安全的实现方式，能防止反射和反序列化攻击。

在实际开发中，静态内部类和枚举是两种最被推崇的单例模式实现方式。如果需要懒加载，静态内部类是绝佳的选择；如果不需要懒加载，或者对防止反射和反序列化有强烈的需求，枚举则是最简单且最安全的方式。

Next.js 项目中 i18n 多语言实现详解

Sun, 13 Jul 2025 00:00:00 GMT

在现代 Web 开发中，国际化（i18n）已成为构建全球化应用不可或缺的一部分。

Next.js 相关架构下，一般可以基于 next-intl 的国际化实现方式，本文将从代码结构、配置方式到实际使用场景，全面介绍 i18n的使用，包括语言配置、翻译消息加载、路由支持、组件使用等核心知识点。

一、i18n 实现基础

1.1 使用 next-intl 库实现国际化

用 next-intl 库来实现国际化功能。该库为 Next.js 提供了完整的国际化解决方案，包括翻译、日期格式化、数字格式化等功能。

1.2 安装与依赖管理

项目使用 pnpm 作为包管理器，安装 next-intl 及其相关依赖非常简单：

pnpm add next-intl

1.3 语言配置文件

语言配置主要定义在 /src/config/website.tsx 文件中，包含默认语言和所有支持的语言列表：

// /src/config/website.tsx
export const websiteConfig = {
  i18n: {
    defaultLocale: 'en',
    locales: {
      en: { flag: '🇺🇸', name: 'English' },
      zh: { flag: '🇨🇳', name: '中文' }
    }
  }
};

此配置不仅用于控制应用的默认语言，还被多个组件引用，如语言切换器、页面标题生成等。

二、翻译消息文件

2.1 翻译消息文件结构

翻译消息存储在 /messages/.json 文件中，按模块划分，例如 "Common"、"PricingPage" 等：

{
  "Common": {
    "login": "Log in",
    "logout": "Log out",
    "language": "Switch language"
  },
  "PricingPage": {
    "title": "Pricing",
    "description": "Choose the plan that works best for you"
  }
}

2.2 在客户端组件中使用翻译

在客户端组件中，使用 useTranslations 钩子获取翻译内容：

import { useTranslations } from 'next-intl';

export default function DashboardPage() {
  const t = useTranslations();
  return (
    {t('Dashboard.dashboard.title')}
  );
}

2.3 在服务端组件中使用翻译

在服务器端组件中，使用 getTranslations 获取翻译内容：

export async function generateMetadata({
  params,
}: {
  params: Promise<{ locale: Locale }>;
}): Promise {
  const { locale } = await params;
  const pt = await getTranslations({ locale, namespace: 'AuthPage.login' });
  return constructMetadata({
    title: pt('title'),
  });
}

三、路由国际化配置

3.1 动态路由 `\[locale\]` 支持

Next.js 的 App Router 支持通过动态路由 \[locale\] 来处理不同语言版本的页面请求。路由配置文件位于 /src/i18n/routing.ts，定义了支持的语言列表和默认语言：

// /src/i18n/routing.ts
export const routing = defineRouting({
  locales: LOCALES,
  defaultLocale: DEFAULT_LOCALE,
  localeDetection: false,
  localeCookie: {
    name: LOCALE_COOKIE_NAME,
  },
  localePrefix: 'as-needed',
});

3.2 自动检测语言与 Cookie 记忆

设置 localeDetection: false 禁用浏览器自动检测语言的功能。用户语言偏好通过 cookie (NEXT\_LOCALE) 记忆。

四、语言切换组件与导航链接

4.1 语言切换组件

可以实现多个语言切换组件，如 LocaleSwitcher 和 LocaleSelector，允许用户手动切换语言：

// /src/components/layout/locale-switcher.tsx
import { useTranslations } from 'next-intl';
import { useRouter } from 'next/router';

export default function LocaleSwitcher() {
  const router = useRouter();
  const { locales } = router;
  const t = useTranslations('Common');

  return (
    
  );
}

4.2 带翻译的导航链接

使用自定义的 LocaleLink 组件生成带语言前缀的链接：

import { LocaleLink } from '@/i18n/navigation';

Dashboard

五、TypeScript 类型定义与类型安全

为了确保类型安全并提供更好的开发体验，项目中使用全局类型定义文件 global.d.ts 扩展 AppConfig 接口，提供 Locale 和 Messages 类型定义：

// global.d.ts
import type { routing } from '@/i18n/routing';
import type messages from './messages/en.json';

declare module 'next-intl' {
  interface AppConfig {
    Locale: (typeof routing.locales)[number];
    Messages: typeof messages;
  }
}

该类型定义文件通常位于项目根目录，并需在 tsconfig.json 中显式包含以确保被识别。

此外，还可以通过 fumadocs-ui 提供的 i18n 工具自动生成 Translations 类型定义，确保类型安全和自动补全支持。

六、新增语言的正确做法

当你需要扩展新的语言或新增翻译字段时，应遵循以下步骤：

添加新语言 JSON 文件 到 /messages/ 目录，如 es.json。
在 **website.tsx** 中添加该语言配置，提供国旗、名称等元信息。
在 **routing.ts** 中添加语言支持，同步更新语言列表。
页面中使用 useTranslations('Namespace.key') 即可生效。

这样可以保证国际化系统的一致性和可维护性。

七、国际化布局与上下文注入机制

7.1 LocaleLayout 组件的作用

在 Next.js 的 App Router 中，\[locale\] 路由下的 LocaleLayout 是整个国际化的根布局组件。它的主要职责包括：

加载当前语言的翻译消息文件（如 /messages/en.json 或 /messages/zh.json）
注入国际化上下文，通过 NextIntlClientProvider
设置 HTML 标签的语言属性，确保 SEO 和无障碍支持
包裹页面内容，使所有子组件都能基于正确的语言环境渲染

示例代码片段：

export default async function LocaleLayout({
  children,
  params: Promise<{ locale: string }>
}) {
  // 加载对应语言的消息文件
  const messages = (await import(`@/messages/${locale}.json`)).default;

  return (
    
      
        
          {children}
        
      
    
  );
}

⚠️ 注意：虽然目前项目中未显式导入消息文件，但 NextIntlClientProvider 默认会从 /messages/.json 自动加载翻译消息。

7.2 NextIntlClientProvider 的作用

NextIntlClientProvider 是 next-intl 提供的核心组件之一，它通过 React Context 将翻译数据传递给所有客户端组件。

主要功能：

功能	描述
翻译注入	将 `messages` 注入 React 上下文，使 `useTranslations` 可用
客户端支持	所有使用 `useTranslations` 的组件均可访问翻译键值
本地化格式化	支持日期、时间、数字等本地化格式输出

示例用法：

import { useTranslations } from 'next-intl';

export default function HomePage() {
  const t = useTranslations('HomePage.hero');
  return {t('title')};
}

📌 提示：如果你希望手动控制消息加载方式，可以显式传入 messages 属性给 NextIntlClientProvider。

7.3 整体流程图解

[LocaleLayout]
   ↓
加载 messages/locale.json
   ↓
包裹  注入翻译数据
   ↓
客户端组件通过 useTranslations 获取翻译内容
   ↓
渲染多语言 UI

4. 最佳实践建议

✅ 新增语言时只需添加 /messages/.json 文件即可生效
✅ 在 website.tsx 中注册语言元信息
✅ 在 routing.ts 中同步更新语言列表
❗ 不建议修改 LocaleLayout 的结构，除非你有特殊需求

通过以上机制，可以实现了简洁、可维护且高效的国际化系统，适合大型 SaaS 应用的多语言需求。

八、翻译消息加载机制详解

8.1 为什么没有显式导入翻译消息？

在 /src/app/\[locale\]/layout.tsx 中，你不会看到类似 **import messages from '@/messages/zh.json'** 的代码片段，这是因为 next-intl 提供了自动加载翻译消息的能力。

✅ 自动加载机制

NextIntlClientProvider 默认会从 /messages/.json 路径加载对应语言的消息文件。只要项目结构符合预期（如 /messages/en.json 和 /messages/zh.json 存在），就可以无需手动导入。

示例代码如下：


  {children}

📌 注意：这里并没有传入 messages 属性，表示使用默认的自动加载方式。

⚠️ 手动加载的适用场景

如果你需要自定义路径、延迟加载或调试，可以显式导入并传入 messages 属性：

const messages = (await import(`@/messages/${locale}.json`)).default;

return (
  
    
      
        {children}
      
    
  
);

但目前项目中不推荐这样做，因为结构和配置已完全符合自动加载的要求。

8.2 翻译消息文件路径约定

消息文件必须存放在 /messages/.json。
示例：
- /messages/en.json
- /messages/zh.json

💡 建议：新增语言时只需添加对应的 JSON 文件即可生效，无需修改 layout.tsx。

8.3 加载方式对比

方式	是否需要手动导入	使用场景
✅ 自动加载	否	标准项目结构、消息文件在 `/messages/.json`
🔁 手动加载	是	自定义消息路径、动态加载、服务器渲染等高级用法

8.4 最佳实践建议

✅ 新增语言时只需添加 /messages/.json 文件即可生效
✅ 在 website.tsx 中注册语言元信息
✅ 在 routing.ts 中同步更新语言列表
❗ 不建议修改 LocaleLayout 的结构，除非你有特殊需求

通过以上机制，MkSaaS 模板实现了简洁、可维护且高效的国际化系统，适合大型 SaaS 应用的多语言需求。

九、语言配置的职责划分：website.tsx 与 routing.ts 的作用解析

在 MkSaaS 模板中，国际化（i18n）的语言配置分别定义在两个文件中：

website.tsx：用于提供语言元信息和 UI 显示；
routing.ts：用于控制路由系统中的多语言行为。

9.1 website.tsx：UI 层语言配置

路径: /src/config/website.tsx

示例代码：

i18n: {
  defaultLocale: 'en',
  locales: {
    en: { flag: '🇺🇸', name: 'English' },
    zh: { flag: '🇨🇳', name: '中文' }
  }
}

作用：

定义网站支持的语言列表及默认语言；
提供语言元信息（如国旗、名称），用于 UI 显示；
被多个组件引用，例如语言切换器、页面标题生成等。

📌 这是面向前端 UI 的语言配置，主要用于控制语言选择器、显示标签等。

9.2 routing.ts：框架层语言路由配置

路径: /src/i18n/routing.ts

示例代码：

export const routing = defineRouting({
  locales: LOCALES,
  defaultLocale: DEFAULT_LOCALE,
  localeDetection: false,
  localeCookie: { name: LOCALE_COOKIE_NAME },
  localePrefix: 'as-needed'
});

作用：

配置 App Router 中的国际化路由规则；
控制 URL 是否添加语言前缀（如 /en/about vs /about）；
设置语言检测方式（浏览器自动检测 or cookie）；
定义多语言 Cookie 名称（如 NEXT\_LOCALE）。

📌 这是面向 Next.js 路由系统的语言配置，主要用于控制语言感知的路由行为和请求处理。

9.3 为什么不统一到一个地方？

虽然从表面上看将语言配置合并到一个文件中似乎更简洁，但实际原因如下：

维度	website.tsx	routing.ts
用途	提供语言元信息（UI 层）	控制路由行为（框架层）
使用者	前端组件、翻译钩子	Next.js App Router、中间件
功能	显示语言选项、翻译内容	多语言 URL、Cookie 存储、路由匹配
是否可合并？	❌ 不建议	❌ 不建议

✅ 正确做法：同步更新两处配置

当你新增一种语言（如西班牙语 es）时，应执行以下步骤：

1、在 website.tsx 添加语言配置

i18n: {
  defaultLocale: 'en',
  locales: {
    en: { flag: '🇺🇸', name: 'English' },
    zh: { flag: '🇨🇳', name: '中文' },
    es: { flag: '🇪🇸', name: 'Español' } // 新增语言
  }
}

2、在 routing.ts 更新语言列表

ts // 自动从 websiteConfig 获取语言列表 export const LOCALES = Object.keys(websiteConfig.i18n.locales); // 包含 ['en', 'zh', 'es']

3、创建对应语言的消息文件

/messages/es.json

✅ 总结

问题	回答
为什么要分开配置？	因为 website.tsx 提供 UI 元信息，routing.ts 控制路由行为，二者职责不同。
能否统一？	不建议，违反单一职责原则且可能导致类型冲突。
新增语言应怎么做？	在 website.tsx 添加语言元信息，在 routing.ts 同步更新，并创建对应 JSON 消息文件。

这样设计确保了国际化系统的灵活性和可维护性，是符合最佳实践的结构.

使用 Content Collections 高效管理和渲染文档、博客文章等结构化内容

Sat, 12 Jul 2025 00:00:00 GMT

Content Collections 是一个用于管理内容的模块化工具，常用于从 content/ 目录中提取和处理 .mdx 和 .json 文件，并将其转换为结构化的数据集合。

它非常适合用于文档、博客文章、静态页面等内容驱动型模块的数据建模。

一、安装依赖

确保你已经安装了必要的依赖包，如：

pnpm add @content-collections/core @fumadocs/content-collections

二、配置路径别名（tsconfig.json）

在项目根目录下的 tsconfig.json 中添加路径映射，以便在代码中直接引用 content-collections：

{
  "compilerOptions": {
    "paths": {
      "content-collections": ["./content-collections"]
    }
  }
}

这样你就可以通过以下方式导入内容集合：

import { allPosts } from 'content-collections';

三、创建 content-collections.ts 配置文件

在项目根目录创建或修改 content-collections.ts，定义内容集合。例如：

// content-collections.ts
import { defineCollection, defineConfig } from '@content-collections/core';
import { DEFAULT_LOCALE, LOCALES } from '@/i18n/routing';
import {
  createDocSchema,
  createMetaSchema,
  transformMDX,
} from '@fumadocs/content-collections/configuration';

const docs = defineCollection({
  name: 'docs',
  directory: 'content/docs',
  include: '**/*.mdx',
  schema: (z) => ({
    ...createDocSchema(z),
    preview: z.string().optional(),
    index: z.boolean().default(false),
  }),
  transform: transformMDX,
});

export default defineConfig({
  collections: [docs],
});

1、配置的作用

这个配置文件做了以下几件事：

定义集合：使用 defineCollection 定义了一个名为 docs 的集合。
指定目录：告诉程序去 content/docs 目录下查找 .mdx 文件。
国际化支持：导入国际化相关的语言配置（默认语言和所有支持的语言列表）。
设置 schema：定义 frontmatter 元信息的字段类型和默认值。
数据转换：使用 transformMDX 将 .mdx 文件正文解析为 HTML 并生成目录（TOC）。

在 content-collections.ts 文件中，schema 和 transform 是两个非常关键的配置项，它们分别用于定义内容集合的数据结构和数据转换逻辑。

2、schema 的作用

用途: 定义每个集合中内容的字段类型、默认值和验证规则。处理的数据: 每个 .mdx 或 .json 文件中的 frontmatter（文件头部的元信息）。

实现方式: 使用 Zod 库来创建类型安全的 schema。确保读取的内容具有预期的字段，并对字段进行类型校验。可以设置默认值或可选字段，以提高灵活性。

3、transform 的作用

用途: 对集合中的每一条内容进行自定义转换，生成更复杂或更适用于前端展示的数据结构。

处理的数据: 包括文件路径、frontmatter 元信息以及文件正文内容。

实现方式: 接收原始内容对象 (data) 和上下文 (context) 返回一个经过处理的新对象可以访问其他集合的内容（如作者、分类），进行关联处理

四、创建内容文件

在 content/docs 目录下创建一些 .mdx 文件，例如：

示例：content/docs/introduction.mdx

---
title: Introduction
description: Welcome to the documentation.
date: 2025-07-10T10:00:00Z
published: true
---

# Introduction

Welcome to the documentation of this project.

五、在组件中使用内容集合

现在你可以直接在页面组件中导入并使用这些内容：

示例：src/app/docs/page.tsx

import { allDocs } from 'content-collections';

export default function DocsPage() {
  return (
    
      Documentation
      
        {allDocs.map((doc) => (
          
            {doc.title}
            {doc.description}
          
        ))}
      
    
  );
}

六、构建与运行

确保你的开发服务器正在运行：

pnpm dev

访问 /docs 路由，你应该能看到所有 .mdx 文件的内容被正确渲染出来。

在 package.json 中配置以下命令：

"dev": "concurrently \"content-collections watch\" \"next dev\"",
"build": "content-collections build && next build"

dev: 同时启动内容监听与 Next.js 开发服务器，实现热更新。
build: 先构建内容集合数据，再构建整个 Next.js 应用，确保部署前数据同步完成。

七、编译输出命名规范

在使用 Content Collections 管理内容的项目中，所有集合的完整数据输出文件采用统一命名格式：all.js（如 allPosts.js, allDocs.js）。该命名方式表示“包含某类内容的全部数据”，具有以下特点：

语义清晰：便于开发者快速理解文件用途。
约定优于配置：提升项目一致性，避免歧义。
易于检索：在大型项目中更方便查找特定集合的全部数据。
构建流程集成：由 content-collections.ts 中定义的集合自动构建生成，结合 schema 校验和 transform 处理后输出结构化数据。

建议保持默认命名风格以确保一致性与兼容性，除非构建工具明确支持自定义输出格式。

八、总结

总之，content-collections 提供了一种高效的方式来管理和渲染文档、博客文章等结构化内容。通过合理配置，可以大幅提升开发效率和内容维护能力。

所有内容文件放在 content/ 目录下按类别组织
schema 中使用 Zod 进行类型校验，确保数据一致性
transform 函数用于生成路由、关联其他集合数据、计算阅读时间等
每个集合需定义 name, directory, include, schema, transform
集合名称建议使用复数形式（如 posts, docs）；输出文件自动命名为 all.js（如 allPosts.js）
可通过封装中间层统一导出所有集合数据：@/lib/content/index.ts
确保 .mdx 文件 frontmatter 符合 schema 定义的字段类型
多语言支持可通过文件名后缀识别（如 file.en.mdx, file.zh.mdx）

Android 中监听 Home 键与 Overview 键的实现原理

Fri, 11 Jul 2025 00:00:00 GMT

在 Android 开发中，出于安全和隐私考虑，系统默认不会为 Home 键或 Overview 键（最近任务键）发送全局广播。然而，在某些场景下（如埋点、行为统计、通知触发等），我们仍然需要感知这些按键事件的发生。

本文将详细讲解如何通过 ACTION\_CLOSE\_SYSTEM\_DIALOGS 广播来间接监听这些按键，并对比 动态注册广播接收器 与 静态注册广播接收器 。

一、实现原理：监听 `ACTION\_CLOSE\_SYSTEM\_DIALOGS`

1.1 原理概述

虽然不能直接监听 Home 键或 Overview 键的按下动作，但可以通过监听系统广播 Intent.ACTION\_CLOSE\_SYSTEM\_DIALOGS 来“推测”用户是否按下了这些按键。

该广播会在以下情况被触发：

用户按下 Home 键
用户按下 Overview 键（Recent Apps）

1.2 获取关闭原因字段

在接收到广播后，通过以下方式获取关闭对话框的原因：

String reason = intent.getStringExtra("reason");

常见值包括：

值	含义
`"homekey"`	用户按下了 Home 键
`"recentapps"`	用户按下了 Overview 键

1.3 示例代码

通过下面的代码，注册广播接收器，监听系统广播，达到识别用户按钮的目的。

public class TouchKeyReceiver extends BroadcastReceiver {
    private static final String SYSTEM_DIALOG_REASON_KEY = "reason";
    private static final String SYSTEM_DIALOG_REASON_RECENT_APPS = "recentapps";
    private static final String SYSTEM_DIALOG_REASON_HOME = "homekey";

    @Override
    public void onReceive(Context context, Intent intent) {
        if (Intent.ACTION_CLOSE_SYSTEM_DIALOGS.equals(intent.getAction())) {
            String reason = intent.getStringExtra(SYSTEM_DIALOG_REASON_KEY);
            if (SYSTEM_DIALOG_REASON_RECENT_APPS.equals(reason)) {
                // Overview 键
            } else if (SYSTEM_DIALOG_REASON_HOME.equals(reason)) {
                // Home 键
            }
        }
    }
}

二、广播注册方式对比：动态 vs 静态

Android 提供了两种注册广播接收器的方式：动态注册 和 静态注册。它们在生命周期、使用场景、兼容性等方面有明显差异。

2.1 动态注册和静态注册的特点对比：

特性	动态注册
注册位置	Java/Kotlin 代码中（如 `onCreate()` 方法内）	在 `AndroidManifest.xml` 文件中声明
生命周期	依赖于组件（如 Activity 或 Application）	应用安装后即可接收广播
触发条件	应用运行时才能接收广播	即使应用未运行，系统也会尝试唤醒进程处理广播
灵活性	可根据需要动态添加/移除监听	Android 8.0+ 对隐式广播限制较多
权限控制	支持 `Context.RECEIVER\_EXPORTED` 控制外部访问	默认 `exported=false`，需显式设置才可接收外部广播

2.2 动态示例代码

IntentFilter filter = new IntentFilter(Intent.ACTION_CLOSE_SYSTEM_DIALOGS);
registerReceiver(taskKeyReceiver, filter, Context.RECEIVER_EXPORTED);

2.3 静态注册示例

三、Android 8.0+ 的广播限制

广播类型	是否支持静态注册	备注
`ACTION\_CLOSE\_SYSTEM\_DIALOGS`	❌ 不支持	包括 Home 键和 Recent Apps 键事件
`ACTION\_USER\_PRESENT`（解锁）	✅ 支持	可以静态注册
自定义广播	✅ 支持	需要配置 `exported=true` 和权限

⚠️ 随着 Android 系统版本升级，Google 对后台广播的限制越来越多，尤其是系统广播。从 Android 8.0 开始，很多系统广播（如 ACTION_CLOSE_SYSTEM_DIALOGS）不再支持静态注册，比如上面的关播接收器需要进行动态注册。

四、扩展建议

对于需要“持久化”监听广播的场景，可以结合 Service 或 JobScheduler 实现保活；
使用 WorkManager 替代传统广播机制，适应 Android 10+ 的后台限制；
对于自定义广播，建议使用 LocalBroadcastManager 提高安全性与性能；
如果广播逻辑复杂，建议封装成独立模块并配合 LiveData 或 EventBus 使用。

Github 仓库操作— token使用，Action 操作权限

Fri, 04 Jul 2025 00:00:00 GMT

由于最近有在 mac 上操作多个 Github 账号代码库的情况。

记得之前操作的方式，是配置 ssh key等操作权限，需要在 mac 隐藏目录.ssh下面的known_hosts文件进行编辑，将相应 key 填写进去。

或者使用用户名密码操作的方式，不过随着 GitHub 对用户安全要求的提升，GitHub 已经停止了对基于用户名和密码的访问认证，改为使用 Personal Access Token（个人访问令牌） 来进行身份认证。

1、使用 Personal Access Token（个人访问令牌）操作不同账号的代码库

又比如在使用GitHub的时候, 提交命令 git push 时，可能会遇到以下错误提示：

$ git push
Usernamefor 'https://github.com': Username
Passwordfor 'https://Username@github.com':
remote: Invalid username or password.
fatal: Authentication failedfor 'https://github.com/username/repository.git/'

解决办法就是使用最新的 **Personal Access Token (PAT) **的方式操作代码仓库。

1.1 创建 Personal Access Token

创建令牌 Token的页面，输入 name、选择过期时间、仓库权限等等，填好之后最下面点击Generate token（生成令牌） 按钮，生成新的访问令牌。

注意：令牌生成后只会显示一次，请立即复制并妥善保存。此令牌将用于后续的 Git 操作。

1.2 使用令牌进行 Git 操作

当你下次运行 git push 或其他需要身份认证的 Git 操作时，使用生成的访问令牌作为密码即可。示例操作：

$ git push
Usernamefor 'https://github.com': your_username
Passwordfor 'https://github.com': <生成的Personal Access Token>

或者更简单的，将 token 填入到远程仓库 url 路径里**【不要忘记@符号】**，比如操作：

拉取github仓库：
git clone https://[token]@github.com/username/xxx.git

添加远程仓库：
git remote add origin https://[token]@github.com/username/xxx.git

如果是配合 sourcetree 进行操作，可以在仓库设置里，远程仓库进行编辑，添加 **[token] @ **到远程仓库URL 路径里，这样就不用每次都输入访问令牌的密码了。

2、给Github Action 相关权限

之前写过几期使用 Github Action 自动执行任务、部署的教程，比如定时部署到 Vercle、Netlify上，就是定时执行 hook 地址，就可以触发一次部署了，没有涉及到 action 修改代码提交的情况。

使用 Github Action自动执行Vercel 部署

使用自定义 GitHub Actions CI/CD 部署到 Vercel

GitHub Actions：带有输入的调度和计划工作流程

不过最近写了一个 bing 壁纸预览和下载的学习网站，有每天定时获取最新 bing wallpaper 数据，提交到代码仓库中，然后再进行部署。

在调试的过程中，开始失败就是忘记了设置代码库的 github action 权限，这里记录一下。

错误日志：
ERROR - Write access to repository not granted

remote: Write access to repository not granted.
fatal: unable to access 'https://github.com/xxx/xxx/': The requested URL returned error: 403
Error: Process completed with exit code 128.

设置路径在：你的代码仓库 → Settings -> Actions -> General

给定权限之后，再进行执行 github action 编写的 workflow 就没有错误问题了。

4.0 版本之后-在Mac上通过脚本实现微信双开[最新4.0.6.17版本]

Thu, 03 Jul 2025 00:00:00 GMT

之前[4.0 版本之前—在Mac上通过脚本实现微信双开] 随着 mac 版本和微信版本的更新，已经失效。

下面以 双开4.0.6.17版（最详细教程）举例。4.0.4、4.0.4、4.0.5 版本同理。

1、原理

复制微信应用并修改签名，使系统识别为不同应用。用此方法也不影响微信输入法的正常使用。

2、适配版本

已测试可支持的，适配微信版本（MAC）

4.0.5.12（2025-05-15 已验证）
4.0.3.93（2025-04-16 已验证）

3、操作步骤

第一步：创建微信的「分身」

执行如下命令，复制微信应用

sudo cp -R /Applications/WeChat.app /Applications/WeChat2.app

会要求输入密码，直接输入即可。

第二步：给 WeChat2.app

修改BundleID，防止微信检测为同一应用

sudo /usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.tencent.xinWeChat2" /Applications/WeChat2.app/Contents/Info.plist

就是通过 Set CFBundleIdentifier com.tencent.xinWeChat2 鉴权的。

第三步：重新签名应用

第二步的延续，签名应用。输入如下命令，如果提示输入密码，输入即可。

sudo codesign --force --deep --sign - /Applications/WeChat2.app

第四步：启动双开

手动打开第一个微信（原应用）；在终端执行如下命令，运行第二个微信，创建方法体。

nohup /Applications/WeChat2.app/Contents/MacOS/WeChat >/dev/null 2>&1 &

第五步：常驻程序坞

第二个终端应用启动后，可以选择右键在程序坞中保留，这样下次直接点程序坞的程序就可以运行了，不需要再次使用终端命令打开第二个微信。

至此，我们的微信双开就完成了，有需要三开的，重复第二到第八步，将步骤中所有的wechat2.app都改成wechat3.app，就可以实现3开了。

4.0 版本之前—在Mac上通过脚本实现微信双开

Thu, 12 Jun 2025 00:00:00 GMT

注意：下面这种方法只适用于 mac 微信4.0 版本之前。验证Version. 3.8.10 (28632)是可以的。

可以参见**4.0 版本之后-在Mac上通过脚本实现微信双开[最新4.0.6.17版本]**** **最新微信版本上实现双开的处理办法。

本文主要介绍了如何在Mac上通过脚本实现微信双开，并通过自动操作创建应用程序，修改图标后直接当作第二个微信使用，无需打开终端输入代码，且双开后无终端出现。

1 、基本原理

如果您不想理解原理，或者不懂Shell，可以直接跳转到最后章节。

使用Linux nohup命令实现，将微信主程序输出到一个“黑洞”里，即使此时关掉终端也不会影响双开微信的运行。

将以下代码复制到终端（Teriminal）运行，即可开启第二个微信，开启后，关闭终端也可以正常运行。

nohup /Applications/WeChat.app/Contents/MacOS/WeChat > /dev/null 2>&1

弊端是每次都需要复制此代码到终端，非常不优雅，接下来的章节介绍如何使用自动操作打包。

2 、使用自动操作打包脚本

自动操作（Automator）是Mac电脑上自带的一款软件，通过设置，可以实现电脑上的大部分操作自动进行，可以简单理解为一个更加硬核的快捷指令（Shortcuts）。

在启动台找到自动操作（Automator），点开打开。

选择新建文稿

选择文稿类型为应用程序。

找到实用工具——运行Shell脚本，双击或者拖拽至右侧空白处。

复制代码至文本框，Shell类型默认/bin/zsh或/bin/bash即可。

nohup /Applications/WeChat.app/Contents/MacOS/WeChat > /dev/null 2>&1

保存文件（Cmd+S），名称随意，位置选择应用程序（Applications），文件格式选择应用程序，存储即可。

打开启动台，图标出现，点击即可启动第二个微信。

3、嫌丑换图标

这个图标只是脚本启动APP的图标，脚本执行之后出现的第二个微信还是原版本的，如果还是嫌丑就改图标，自己设计或者去网上找一个心仪的图标。我喜欢这个黑白的，因为有植物大战僵尸里面模仿者（Imitater）的感觉。

复制（Cmd+C）下载好的图标文件。

在应用程序（Applications）文件夹里找到刚保存的脚本程序，右击图标，点击显示简介。

点击右上方的小图标，周围变蓝即可，然后粘贴（Cmd+V），即可完成。

效果展示及懒人包

把双开启动软件放在dock栏，点击之后就可以实现微信双开，而且全程无终端打开，也不会出现其他方法中关闭终端，第二个微信就关闭的情况。

同样的，如果更改代码，也可以实现其他软件的双开，可以自行探索。

如果你实在太懒了，不想操作，那么点击下面链接，下载我修改好的可以直接使用。

阿里网盘—若依系列框架视频教程大全

Tue, 10 Jun 2025 00:00:00 GMT

RuoYi 是一个 Java EE 企业级快速开发平台，基于经典技术组合（Spring Boot、Apache Shiro、MyBatis、Thymeleaf、Bootstrap），内置模块如：部门管理、角色用户、菜单及按钮授权、数据权限、系统参数、日志管理、通知公告、代码生成等。在线定时任务配置；支持集群，支持多数据源，支持分布式事务。

1、若依框架系列视频教程（RuoYi 前端不分离版本）

视频教程（共115节）

RuoYi是一个后台管理系统，基于经典技术组合（Spring Boot、Apache Shiro、MyBatis、Thymeleaf）主要目的让开发者注重专注业务，降低技术难度，从而节省人力成本，缩短项目周期，提高软件安全质量。

引导你逐步理解若依框架的核心功能和应用技巧。

教程内容 ├── 1 项目概述 ├── 2 环境部署 ├── 3 war包部署到tomcat ├── 4 文件结构介绍 ├── 5 配置文件介绍 ├── 6 SpringBoot简介 ├── 7 服务器配置 ├── 8 多环境使用 ├── 9 配置文件获取 ├── 10 自定义资源映射 ├── 11 缓存使用 ├── 12 异步调用 ├── 13 定时任务 ├── 14 热部署 ├── 15 Shiro简介 ├── 16 登录实现 ├── 17 退出实现 ├── 18 记住我实现 ├── 19 验证码实现 ├── 20 权限控制实现 ├── 21 会话实现

├──。。。 ├── 114 档案系统部署使用 ├── 115 4.8.1更新介绍

若依框架系列视频教程 - 前端不分离版本 - 带源码课件 https://www.alipan.com/s/ijsSiNUf1vt 提取码: k94j 点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，视频原画倍速播放。

2、若依框架系列视频教程（RuoYi-Vue 前后端分离版本）。

视频教程（共137节） RuoYi-Vue 是一个 Java EE 企业级快速开发平台，基于经典技术组合（Spring Boot、Spring Security、MyBatis、Jwt、Vue），内置模块如：部门管理、角色用户、菜单及按钮授权、数据权限、系统参数、日志管理、通知公告、代码生成等。在线定时任务配置，支持集群，支持多数据源，支持分布式事务等。

专为前端开发者设计的Vue.js集成教程，深入讲解如何与后端若依框架无缝对接。

教程内容 ├── 01 项目概述 ├── 02 项目运行 ├── 03 构建发布到Linux ├── 04 系统菜单介绍 ├── 05 开发环境运行 ├── 06 表结构介绍 ├── 07 目录文件介绍 ├── 08 主配置文件介绍 ├── 09 Spring Boot 简介 ├── 10 Spring Security 简介 ├── 11 Spring Security 配置介绍 ├── 12 Spring Security 密码加密 ├── 13 Spring Security 退出配置 ├── 14 Spring Security 登录配置 ├── 15 Spring Security 权限讲解 ├── 16 Spring Security 权限注解 ├── 17 JWT 介绍 ├── 18 JWT 实现 ├── 19 JWT 过滤器

├── 。。。 ├── 136 3.8.9版本更新介绍 ├── 137 3.9.0版本更新介绍 ~~

若依框架系列视频教程 - 前后端分离版本 - 带源码课件 https://www.alipan.com/s/fcKDRjwY8rX 提取码: 0ue1 点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，视频原画倍速播放。

3、若依框架系列视频教程（RuoYi-Cloud微服务版本）。

视频教程（共146节）

针对微服务架构爱好者，、涵盖从微服务架构设计到具体实现的全过程。

RuoYi-Cloud 是一个 Java EE 分布式微服务架构平台，基于经典技术组合（Spring Boot、Spring Cloud & Alibaba、Vue、Element），内置模块如：部门管理、角色用户、菜单及按钮授权、数据权限、系统参数、日志管理、代码生成等。在线定时任务配置；支持集群，支持多数据源。

教程内容

├── 01 项目概述 ├── 02 微架构概念 ├── 03 微架构及选型 ├── 04 目录文件介绍 ├── 05 项目运行 ├── 06 构建发布到Linux ├── 07 开发环境运行 ├── 08 服务网关介绍 ├── 09 创建使用服务网关 ├── 10 网关路由规则 ├── 11 网关路由配置 ├── 12 网关限流配置 ├── 13 网关熔断降级 ├── 14 网关跨域配置 ├── 15 网关黑名单配置 ├── 16 网关白名单配置 ├── 17 网关全局过滤器 ├── 18 网关实现Sentinel限流 ├── 19 Sentinel分组限流 ├── 20 Sentinel自定义异常

├──。。。。。 ├── 132 定时任务相关使用 ├── 133 定时任务实现详解

若依框架系列视频教程 - 微服务版本 https://www.alipan.com/s/unQTyDeSEU2 提取码: 3uf1 点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，视频原画倍速播放。

git仓库同步两个远程仓库

Fri, 16 May 2025 00:00:00 GMT

假设有两个存储库 URL，并希望同步它们以便它们包含相同的内容。

必须在 Git 中配置一个指向上游仓库的远程仓库，以便将您在分支中所做的更改同步到原始仓库。这也允许您将原始仓库中的更改同步到分支中。

若需双向同步（配置远程仓库 origin、upstream），举例拉取 unpstream 最新代码，同步到 master 分支，可采用以下方法：

1. 配置双远程仓库

查看你的 fork 当前配置的远程仓库地址：

$ git remote -v
 origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
 origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)

指定当前 fork 将要同步的上游远程仓库地址：

$ git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITO

2.验证一下你刚指定的上游仓库地址：

$ git remote -v
 origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
 origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
 upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
 upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

3. 拉取所有远程更新

从上游仓库拉取分支及其对应的提交记录。对于 master 的提交会保存在一个本地分支 upstream/master 里。

$ git fetch upstream
 remote: Counting objects: 75, done.
 remote: Compressing objects: 100% (53/53), done.
 remote: Total 62 (delta 27), reused 44 (delta 9)
 Unpacking objects: 100% (62/62), done.
 From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY
 * [new branch] master -> upstream/master

4. 合并并推送

签出你的 fork 的本地 master 分支

$ git checkout master
 Switched to branch ‘master’

把 upstream/master 中的变更合并到本地的 master 分支里。这样你的 fork 的 master 分支就和上游仓库同步了，也不会丢失本地的更改。

$ git merge upstream/master
 Updating a422352..5fdff0f
 Fast-forward
 README | 9 — — — -
 README.md | 7 ++++++
 2 files changed, 7 insertions(+), 9 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md

把更改推送到服务器：

$ git push

通过llms.txt文件让AI更容易的收录你的网站内容

Sun, 11 May 2025 00:00:00 GMT

llms.txt 是一个专为大型语言模型（Large Language Models，简称 LLMs）设计的文本文件，类似于 robots.txt，但目的不同。robots.txt 告诉搜索引擎爬虫哪些页面可以爬取，而 llms.txt 则是为 AI 工具提供网站内容的结构化信息，帮助 AI 更好地理解和索引网站内容。

llms.txt 的名称中的 "llms" 代表 "Large Language Models"，表明这个文件是专门为大型语言模型设计的。

一、llms.txt 的由来

随着 ChatGPT、Claude 等 AI 工具的普及，开发者希望这些 AI 工具能够更好地理解和索引他们的文档。然而，AI 工具在抓取和理解网站内容时面临着一些挑战：

网站结构复杂，AI 难以理解内容之间的关系
网站内容可能分散在多个页面，AI 难以获取完整信息
网站可能包含动态内容，AI 难以抓取

为了解决这些问题，一些开发者和 AI 公司开始探索一种标准化的方式，让网站所有者能够主动向 AI 工具提供网站内容的结构化信息。这就是 llms.txt 的由来。

相关标准对比

文件类型	主要功能	目标用户
robots.txt	控制爬虫访问权限	搜索引擎爬虫
sitemap.xml	提供可索引页面列表	搜索引擎
llms.txt	优化内容结构呈现	AI系统

二、llms.txt 的规范

标准定义了两类文件：

基础文件(/llms.txt)：作为核心导航指南，概述网站主要内容框架
扩展文件(/llms-full.txt)：可选补充文件，包含完整内容细节供深度查询使用

机器人协议配置在robots.txt中添加AI爬虫专用规则

# 基础访问规则
User-Agent: *
Allow: /

# AI爬虫特殊处理
User-Agent: GPTBot
Allow: /llms.txt
Disallow: /

User-Agent: anthropic-ai
Allow: /llms.txt
Disallow: /

# 搜索引擎爬虫
User-Agent: Googlebot
Allow: /

# AI内容引导
LLM-Content: https://yourdomain.com/llms.txt
LLM-Full-Content: https://yourdomain.com/llms-full.txt

1、基础文件(`llms.txt`)：

作为核心导航指南，概述网站主要内容框架

llms.txt 文件通常放置在网站的根目录下，例如 https://example.com/llms.txt。它的内容格式比较自由，但通常包含以下几个部分：

网站标题和描述：简要介绍网站的主题和内容
内容目录：列出网站的主要页面和链接
内容摘要：提供网站主要内容的摘要

下面是一个简单的示例：

# 网站标识
[网站名称]

> 价值主张：用简洁语句说明网站核心价值

## 内容架构
- [分类1](链接)：内容特性说明
- [分类2](链接)：内容特性说明
- [文章专栏](链接)：内容形式描述

## 关键页面
- [核心页面1](链接)：功能概述
- [核心页面2](链接)：功能概述

## 近期更新
- [新内容1](链接)：更新时间
- [新内容2](链接)：更新时间

2、扩展版本 `llms-full.txt`

此外，还有一个扩展版本 llms-full.txt，它包含网站的完整内容，让 AI 工具能够获取网站的所有信息。下面是一个简单的示例：

# 网站全景介绍

> 详细说明（100-150字）：目标用户、核心优势、差异化特点

## 建站理念
阐述创办初衷和发展愿景（200-300字）

## 内容体系
### [主分类1](链接)
深入说明内容特色和用户收益（150-200字）

### [主分类2](链接)
深入说明内容特色和用户收益（150-200字）

## 用户获益
具体描述能解决哪些问题（200-300字）

## 内容更新
### [最新文章1](链接)
核心观点和价值提炼（100-150字）

### [最新文章2](链接)
核心观点和价值提炼（100-150字）

三、llms.txt 的作用

llms.txt 是放置在网站根目录下的 Markdown 文件，包含结构化内容导航和核心信息摘要。其标准由 Answer.AI 联合创始人 Jeremy Howard 提出，目的是解决传统网页（如复杂 HTML 元素）对 AI 处理效率的干扰。主要作用如下：

优化 AI 内容处理
- 过滤冗余信息：去除导航栏、JavaScript 等非必要元素，直接为 AI 提供“纯净”文本。
- 结构化呈现：通过标题（H1/H2）和列表划分内容模块，帮助 AI 快速理解网站架构。
- 上下文管理：适应 AI 的有限上下文窗口，优先提供关键内容。
控制 AI 访问权限
- 指定允许抓取的页面路径（如 /docs），排除敏感或无关内容（如 /admin）。
- 声明内容使用规则（如引用授权、禁止商用）。
提升生成结果质量
- 标注关键词和术语，增强 AI 对专业领域内容的理解。
- 通过 llms-full.txt 提供完整文档细节，供 AI 深度查询。

四、llms.txt 的生成工具与实操指南

4.1、自动化工具

4.1.1、Firecrawl LLMs.txt Generator：

Firecrawl LLMs.txt Generator 支持输入网址自动生成文件，提供 API 接口，适合技术文档站。

4.1.2、SiteSpeakAI：

SiteSpeakAI LLMs.txt Generator 免费在线工具，一键抓取网站内容并生成标准化文件。

4.1.3、Mintlify：

Mintlify 托管文档平台（如技术文档）可自动生成并部署 llms.txt 和 llms-full.txt。

4.2、开发插件：vitepress-plugin-llms

vitepress-plugin-llms 是一个专为 VitePress 文档网站设计的插件，它可以自动生成 llms.txt 和 llms-full.txt 文件，让你的 VitePress 文档更好地被 AI 工具理解和索引。

尤雨溪推荐的 VitePress 插件，安装后自动生成文件并集成到文档站。

npm install vitepress-plugin-llms -D

配置 VitePress 后，文件将自动生成至根目录。

4.3、快速生成方法

URL 转换工具，访问 https://llmstxt.new/你的网站域名（如 llmstxt.new/https://example.com），系统自动抓取并生成 Markdown 格式文件。

五、注意事项

内容质量优先：需配合原创优质内容，仅技术优化无法替代内容价值。
持续更新：定期更新 llms.txt 可建立 AI 信任度，提升收录优先级。
兼容性验证：使用工具生成后，建议通过 LLMs TXT Hub 校验文件格式。

通过上述工具和方法，开发者可快速为网站生成符合标准的 llms.txt 文件，显著提升 AI 对内容的理解与应用效率。

实用工具推荐

[1] Firecrawl LLMs.txt Generator :https://llmstxt.firecrawl.dev/

[2] SiteSpeakAI LLMs.txt Generator : https://sitespeak.ai/tools/llms-txt-generator

[3] apify/actor-llmstxt-generator : https://github.com/apify/actor-llmstxt-generator

[4] WordLift AI-Powered SEO Generator : https://wordlift.io/generate-llms-txt/

[5] Mintlify : https://mintlify.com/docs/settings/llms

总结

llms.txt 为 AI 工具提供了一种统一的方式来获取和理解网站内容，而 vitepress-plugin-llms 插件则让 VitePress 文档网站轻松支持这一标准。通过在 Wot Design Uni 项目中引入这一插件，我们让 AI 工具能够更好地理解和索引我们的文档内容，为用户提供更准确、更有价值的信息。

随着 AI 技术的不断发展，llms.txt 标准可能会得到更广泛的支持和应用。作为开发者，我们可以通过引入这一标准，让我们的文档在 AI 时代保持良好的可访问性和可发现性。

基于 Cloudflare 创建无限多企业邮箱

Tue, 29 Apr 2025 00:00:00 GMT

Cloudflare是一家提供CDN、网络安全、DDos防御和域名服务的公司。人称大善人，赛博活佛，爬爬虾之前介绍过cloudflare的DNS，内网穿透等免费服务。

今天这里主要介绍如何从Cloudflare 白嫖无限多个企业级邮箱，瞬间获得无限多个免费邮箱，这些邮箱既可以收邮件，也可以发邮件。

首先域名邮箱，可以用来接收网站验证码，注册账户的时候就可以很方便的注册一大堆小号。还可以把他们当成临时邮箱，与人通信，避免暴露自己真实的邮箱，保护个人隐私。

1、域名

使用Cloudflare的前提是要有一个域名。

有了域名以后，把它托管到Cloudflare上。登录到Cloudflare之后，右上角点击添加站点，输入你的域名。

然后继续，这里有一些付费的，我们都不要，直接找下面这个免费的，点击继续。

一路点击下一步。这步是重点，更改名称服务器。找到这两个名称服务器。

我们需要去刚才买域名的网站更改一下，这里有一个Name Server。就把这里改一下，把原来的这3条全部删掉，然后填上刚才网站给我分配的这两个，点击保存。

我们再回到Cloudflare，点击立即检查，然后点击继续。这里什么都不用动，直接开始使用就可以了。

左上角点击Cloudflare的图标，回到首页，域名这里打上一个对勾，那就可以开始直接使用了。

2、收邮件

这里以域名tech-shrimp.com，我们先点击这个域名，进来以后选择左侧电子邮件，选择电子邮件路由。

第一次进来以后，会有一个新手设置，点击取消新手设置，点击启用电子邮件路由。

这里面有4个DNS值，我们点击添加记录并启用，Cloudflare就会自动添加上这4个DNS记录。

弄好以后，我们再点击路由规则，这里有一个catch-all地址，我们点击右侧的编辑，

点击发送到电子邮件。这里填写一个自己的电子邮箱，然后点击保存。

保存好以后，这里会出现一个待验证。

Cloudflare会发送一封验证邮件到这个地址，我们来接收一下。刷新一下页面，打上一个对勾，那就配置完成了。

这个配置的意思是所有发送到tech-shrimp.com域名下面的邮件都会自动转到163的邮箱 。这样就实现了无限多个邮箱可以收邮件。

3、发邮件

使用邮箱发送邮件，我使用的服务是**resend.com** ，这也是一个免费的服务。没有账号的话就自己注册一个。

选择左侧的API Keys，点击create API Key，名字随便填一个，下面两个保持默认，点击添加。

就会获得一个API Key，把它保存好。这里有一个域名，我们需要把域名也添加到这个网站上，就是刚才托管到Cloudflare的那个域名。

好，这一步是重点 。这里给了3个DNS记录，我们需要把这个记录填回Cloudflare。

回到cloudflare。

我们回到resend，有一个按钮verify DNS records，我们点击一下，它检查我们刚才的配置是否正确。等校验完，页面标成绿色，那就配置完成了。

使用Python发邮件

# 先安装依赖# pip install resend
import resend
# 这里换成自己的resend API Key
resend.api_key = "re_xxxxxxxxxxxxxxxxxxxxxxx"

params: resend.Emails.SendParams = {
# 发件人可以是自己域名下的任何一个人"from": "sdkjfskdhf@你的域名",
  "to": ["tech-shrimp@outlook.com"],
  "subject": "hi",
  "html": "hello, world!"
}

email = resend.Emails.send(params)
print(email)

使用cURL发邮件

Authorization 换成自己的resend API Key

发件人可以是自己域名下的任何一个人

curl -X POST 'https://api.resend.com/emails' \
 -H 'Authorization: Bearer re_VxeNCEn1_6w4bYF93xQKgKGFYRxNK2D3J' \
 -H 'Content-Type: application/json' \
 -d
```{
  "from": "Acme ",
  "to": ["tech-shrimp@outlook.com"],
  "subject": "hello world",
  "text": "it works!"
}'

如何切换 google play 账号到美区，锁定美区实现ChatGPT应用无障碍下载

Sun, 20 Apr 2025 00:00:00 GMT

由于 ChatGPT 在某些国家无法使用，在 google play 应用商店上对于某些地区也无法下载。一般显示类似“此商品无法在您所在的国家/地区购买或下载”的提示。

这时候你可能想从一些第三方应用商店，比如 APKPure、apkmirror上搜索下载 apk 进行安装，虽然能够成功安装了，但是无法打开运行，打开后会跳转到 google 应用商店，然后显示“无法识别您设备上安装的应用，该应用可能会损害您的设备”的提示。

以上这些，根本原因还是该应用没有在你 google play 账号的地区上架，所以无法下载和运行。

要解决这个问题，需要将你 google play 账号锁定到一个合理的地区，比如美区，一般所有的应用都能够下载安装和运行。

下面教你如何将你 google play 账号锁定到美区：

1、查看 google play 账号所在地区

通过 google play 右上角点击个人头像，依次按照如下顺序，进入到“账号和设备偏好设置”中，查看到当前账号所属的国家或地区。

如果为空，说明当前账号未确定到详细地区，可以通过设置付款信息绑定到固定地区。

2、绑定美国信用卡账号锁定到美区

最简单的方法就是账号绑定美国信用卡，可以将 gp 账号锁定到美区。

不过美国信用卡一般人无法满足条件，不过可以使用虚拟信用卡，这类网上也有很多提供这类服务的，经常做出海服务的肯定知道**wildcard这个平台，也称为野卡，注册充值之后可以为你生成美国信用卡，平常用于绑定国外的一些服务，向ChatGPT Plus/Midjourney等海外服务，一般是不支持国内的信用卡的，这时候我们就可以使用wildcard**这个为我们生成的虚拟信用卡来进行绑定。

具体**wildcard这个平台**的介绍，可以参见之前的这篇文章：

野卡WildCard虚拟信用卡全攻略：无需海外卡轻松订阅ChatGPT Plus/Midjourney等50+海外服务

这里 gp 账号在第一步中，账号设置的地方，点击“付款和订阅”，然后绑定申请到美国虚拟信用卡，即可将 gp 账号绑定到美区。

说明：绑定信用卡并不实际扣费，绑定完之后 gp 账号锁定到美区，可以把付款信用卡再解绑即可。

小技巧：

命令行快速打开 google play 应用，例如[xxx 替换为要打开的 google play 应用的正式包名]：

adb shell am start https://play.google.com/store/apps/details?id=xxx

野卡WildCard虚拟信用卡全攻略：无需海外卡轻松订阅ChatGPT Plus/Midjourney等50+海外服务

Fri, 18 Apr 2025 00:00:00 GMT

一、虚拟信用卡：数字时代的安全支付新选择

虚拟信用卡是专为在线交易设计的数字支付工具，通过生成可自定义使用次数的虚拟卡号，完美解决海外订阅场景中的信用卡信息泄露风险。其具备实体卡同等功能（含CVV安全码/有效期），特别适配ChatGPT Plus、MidJourney等热门AI工具的订阅需求。

虚拟信用卡的三大核心优势

金融安全保障：动态卡号隔离真实账户，防范钓鱼网站与交易欺诈
跨境支付利器：支持全球200+国家/地区的数字服务订阅
智能风控管理：单次/多次使用模式自由切换，单日消费额度自定义

二、WildCard虚拟信用卡：中国用户专属的海外支付解决方案

为什么选择WildCard？

作为专为中文用户打造的虚拟信用卡平台，WildCard已服务超10万+用户完成海外AI服务订阅，特别针对OpenAI/ChatGPT的支付场景进行深度优化。

平台亮点功能：

国内手机号直注册，支持支付宝/微信即时充值
5分钟完成ChatGPT Plus升级，成功率高达99%
无需海外身份认证，中文界面零门槛操作

三、3分钟完成注册：WildCard虚拟信用卡开通全流程

新手必看操作指南

官网注册入口：立即开通WildCard （使用邀请码PREMIUM立享开卡费5折+首年0手续费）
选择服务周期：推荐2年套餐享最高性价比（现价$19.99/年）
绑定支付渠道：支持支付宝扫码充值，实时到账无延迟

四、WildCard六大核心功能解析

差异化竞争优势

10秒极速开卡：全程中文引导，无需信用卡申请经验
AI生态全覆盖：ChatGPT/MidJourney/Claude等主流平台即绑即用
零隐藏收费：消费手续费全免，汇率实时透明可查

特色功能详解

ChatGPT Plus一键升级：突破国内信用卡支付限制
智能API路由：自动选择最优网络节点，订阅成功率提升80%
海外验证码服务：支持美国/英国虚拟号码接收短信
多账户管理：单账号可创建5张独立虚拟卡
交易实时提醒：微信/短信双重通知机制

五、费用说明与使用技巧

2024最新资费标准

基础年费：首年$9.99（原价$11.99，输入邀请码立减$2）
充值费率：支付宝充值3.5%手续费，推荐单次大额充值更划算

高效使用贴士

余额预存建议：建议预留$20以上余额保障订阅连续性
账单邮编填写：使用系统自动生成的美国邮编（如10001）
订阅失败处理：切换浏览器隐私模式重新绑定

六、高频问题解决方案库

ChatGPT订阅专项答疑

自动续费关闭指南： ChatGPT账户 → Billing → Cancel Subscription → 确认关闭
支付失败处理方案：使用WildCard专用支付通道，成功率提升至95%

账户安全类问题

风险IP检测：避免使用公共机场节点，推荐WildCard专属加速器
交易异常处理：联系在线客服（工作日9:00-21:00）即时冻结卡片

七、为什么80%的AI从业者选择WildCard？

作为国内虚拟信用卡领域的头部服务商，WildCard凭借以下优势成为技术从业者的首选：

✅ 日均处理OpenAI订阅请求3000+
✅ 7×12小时中文客服即时响应
✅ 行业最低年费套餐（平均每天仅$0.03）

立即通过WildCard官网开通服务，输入邀请码PREMIUM还可额外获得$5充值优惠券！

Next.js 系列之的SSG、SSR、ISR、CSR 的详细介绍和区别

Mon, 07 Apr 2025 00:00:00 GMT

Next.js 提供了多种渲染策略（SSG、SSR、ISR、CSR），每种策略适用于不同的场景。以下是它们的核心区别、实现方式及最佳实践：

1. SSG（Static Site Generation，静态生成）

核心特点

生成时机：在构建时（next build）生成静态 HTML。
数据获取：通过 getStaticProps 获取数据，支持预渲染所有页面。
适用场景：内容不经常变化的页面（如博客、文档、营销页）。
优点：加载最快、SEO 友好、CDN 缓存友好。
缺点：无法实时更新内容，需重新构建才能更新。

实现代码

// pages/blog/[slug].js
export async function getStaticPaths() {
  // 预生成所有可能的路径（如博客文章列表）
  const posts = await fetch('');
  return {
    paths: posts.map(post => ({ params: { slug: post.slug } })),
    fallback: false, // 未预生成的路径返回 404
  };
}

export async function getStaticProps({ params }) {
  // 根据 slug 获取单篇文章内容
  const post = await fetch(`https://api.example.com/posts/${params.slug}`);
  return { props: { post } };
}

export default function BlogPost({ post }) {
  return {post.content};
}

2. SSR（Server-Side Rendering，服务端渲染）

核心特点

生成时机：每次页面请求时在服务端动态生成 HTML。
数据获取：通过 getServerSideProps 在请求时获取最新数据。
适用场景：需要实时数据的页面（如用户仪表盘、实时股价）。
优点：内容始终最新，支持个性化渲染（如基于 Cookie 的权限验证）。
缺点：TTFB（首字节时间）较慢，服务端压力大。

实现代码

// pages/dashboard.js
export async function getServerSideProps(context) {
  // 从请求中获取 Cookie 或用户信息
  const user = await getUserFromCookie(context.req.cookies);
  const data = await fetch(`https://api.example.com/dashboard?user=${user.id}`);
  return { props: { data } };
}

export default function Dashboard({ data }) {
  return {data.stats};
}

3. ISR（Incremental Static Regeneration，增量静态再生）

核心特点

生成时机：SSG 的扩展，允许在运行时按需重新生成静态页面。
数据获取：在 getStaticProps 中设置 revalidate 参数（秒），触发条件： • 初次访问时生成静态页面。 • 后续访问时，若超过 revalidate 时间，后台重新生成页面。
适用场景：内容更新频率适中的页面（如电商产品页、新闻列表）。
优点：兼具 SSG 的速度和 SSR 的更新能力，减轻服务端压力。
缺点：再生成期间用户可能看到旧数据。

实现代码

// pages/products/[id].js
export async function getStaticPaths() {
  return { paths: [], fallback: 'blocking' }; // 动态生成所有路径
}

export async function getStaticProps({ params }) {
  const product = await fetch(`https://api.example.com/products/${params.id}`);
  return {
    props: { product },
    revalidate: 3600, // 每 1 小时重新验证一次
  };
}

export default function Product({ product }) {
  return {product.name};
}

4. CSR（Client-Side Rendering，客户端渲染）

核心特点

生成时机：在客户端浏览器中通过 JavaScript 渲染内容。
数据获取：通过 useEffect 或 SWR 在组件挂载后获取数据。
适用场景：交互性强、无需 SEO 的页面（如用户后台、管理面板）。
优点：减少服务端负载，支持动态交互。
缺点：首屏加载慢，SEO 不友好，依赖客户端 JavaScript。

实现代码

// pages/profile.js
import { useEffect, useState } from 'react';

export default function Profile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // 组件挂载后获取用户数据
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);

  if (!user) return Loading...;
  return {user.name};
}

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

// pages/index.js（SSG 主页面）
export async function getStaticProps() {
  const posts = await fetch('');
  return { props: { posts } };
}

export default function Home({ posts }) {
  // 主内容静态生成，评论模块客户端渲染
  return (
    
      {posts.map(post => )}
      
        
      
    
  );
}

// 客户端组件（仅在浏览器加载）
function Comments() {
  const [comments, setComments] = useState([]);
  useEffect(() => {
    fetch('/api/comments').then(res => res.json()).then(setComments);
  }, []);
  return {comments.map(comment => {comment.text}
)};
}

7. 选择策略的决策树

是否需要 SEO？ • ✅ 是 → 使用 SSG、SSR 或 ISR。 • ❌ 否 → 使用 CSR。
数据是否频繁更新？ • ✅ 是 → 使用 SSR 或 ISR。 • ❌ 否 → 使用 SSG。
是否有个性化内容？ • ✅ 是 → 使用 SSR。 • ❌ 否 → 使用 SSG 或 ISR。

总结

SSG：优先用于内容稳定、SEO 关键的页面。
SSR：用于实时数据或个性化内容。
ISR：平衡速度与更新频率，适合大规模内容站点。
CSR：用于交互复杂、无需 SEO 的功能模块。
混合使用：结合不同策略，最大化性能与功能灵活性。

系列文章

Next.js 系列之客户端组件（Client Components）和服务端组件（Server Components）的区别

Next.js 系列之客户端组件（Client Components）和服务端组件（Server Components）的区别

Next.js 系列之 app router 和 page router 的区别

Sat, 05 Apr 2025 00:00:00 GMT

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 自定义全局布局，无法自动嵌套。

• 手动处理嵌套：需在组件内显式引入布局（如）。

（2）数据加载

App Router

• 服务端数据获取：组件可直接使用 async/await 获取数据（默认为 React Server Component）。

• 并行加载：通过分块加载多个数据源。

• 动态 SEO：通过导出 metadata 对象动态设置页面标题、描述等。

// App Router 页面示例（app/page.js）
export default async function Page() {
  const data = await fetchData(); // 直接异步获取数据
  return {data};
}

export const metadata = {
  title: 'Home Page',
};

Page Router

• 数据方法：需使用 getStaticProps（SSG）、getServerSideProps（SSR）或 getInitialProps（混合渲染）。

• SEO 静态化：需手动在 \_document.js 或页面组件内设置标签。

// Page Router 页面示例（pages/index.js）
export async function getServerSideProps() {
  const data = await fetchData();
  return { props: { data } };
}

export default function Page({ data }) {
  return {data};
}

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，旧项目可逐步迁移以利用新特性。

系列文章

Next.js 系列之客户端组件（Client Components）和服务端组件（Server Components）的区别

Next.js 系列之Serverless（无服务器架构）介绍

Thu, 03 Apr 2025 00:00:00 GMT

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）的区别

Next.js 系列之客户端组件（Client Components）和服务端组件（Server Components）的区别

Tue, 01 Apr 2025 00:00:00 GMT

Next.js 中客户端组件（Client Components）和服务端组件（Server Components）的核心区别在于运行环境、功能特性及适用场景，以下是详细对比：

1. 运行环境与渲染方式

服务端组件

• 环境：仅在服务器端运行，生成静态 HTML 发送到客户端。

• 渲染：支持静态渲染（默认）、动态渲染（需调用 fetch 等 API）和流式渲染（分块加载内容）。

• 示例代码：直接获取数据并返回 HTML，无需客户端交互逻辑。

// 服务端组件示例：直接获取数据并生成静态 HTML
export default async function ServerComponent() {
  const data = await fetch('');
  return {data};
}

客户端组件

• 环境：在浏览器中运行，支持交互逻辑和浏览器 API（如 window、localStorage）。

• 渲染：首次加载时由服务端生成 HTML 预览，随后通过客户端 JavaScript 进行 Hydration（水合）以实现交互性。

• 示例代码：使用 useState 管理状态并响应用户操作。

'use client';
import { useState } from 'react';
export default function Counter() {
  const [count, setCount] = useState(0);
  return ;
}

2. 功能特性

特性	服务端组件	客户端组件
数据获取	可直接访问数据库、API 或敏感数据。	需通过客户端请求（如 `fetch`），数据可能暴露。
React Hooks	不支持 `useState`、`useEffect` 等。	支持所有 React Hooks。
浏览器 API	无法访问。	可访问 `window`、`document` 等。
性能优化	减少客户端 JS 体积，提升 SEO 和首屏加载速度。	增加客户端 JS 体积，但支持动态交互。
嵌套规则	可包含客户端组件。	不可嵌套服务端组件（仅能通过 Props 传递数据）。

3. 适用场景

服务端组件优先使用的情况：

• 静态内容展示（如博客文章、产品列表）。

• 需要直接访问数据库或敏感数据的场景。

• SEO 优化需求高的页面。

客户端组件优先使用的情况：

• 用户交互（如表单提交、按钮点击）。

• 动态状态管理（如购物车、计数器）。

• 依赖浏览器 API 的功能（如动画、地理位置）。

4. 混合使用与数据传递

组合方式：服务端组件可通过 Props 将数据传递给客户端组件。例如：

// 服务端组件（传递数据）
export default async function ServerParent() {
  const data = await fetchData();
  return ;
}

// 客户端组件（接收数据）
'use client';
export default function ClientChild({ data }) {
  const [filter, setFilter] = useState('');
  // 根据 data 进行过滤等操作
}

限制：客户端组件无法直接导入服务端组件，需通过 Props 或占位符传递。

5. 性能与安全

服务端优势：

• 缓存渲染结果，减少重复请求。

• 敏感逻辑（如数据库查询）保留在服务端，避免泄露。

客户端劣势：

• 增加客户端 JS 体积，可能影响加载速度。

• 需谨慎处理用户输入和敏感数据。

总结

服务端组件和客户端组件在 Next.js 中形成互补：

• 服务端组件 侧重于性能优化、数据安全与静态内容渲染。

• 客户端组件 专注于交互性和动态功能。

合理混合使用两者（如服务端获取数据后传递给客户端处理交互），可构建高效且用户友好的应用。

系列文章

https://github.com/utterance/utterances

个税年度汇算时，申报的劳务报酬总收入小于本年度代开的劳务发票总金额，该如何处理？

Tue, 25 Mar 2025 00:00:00 GMT

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 评论组件

Fri, 21 Mar 2025 00:00:00 GMT

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选择器自定义布局和样式。

参考资料

https://utteranc.es/

使用 utterances 作为博客评论组件

XAPK是什么文件，如何在安卓上安装XAPK？

Thu, 20 Mar 2025 00:00:00 GMT

什么是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 Actions CI/CD 部署到 Vercel

Mon, 17 Mar 2025 00:00:00 GMT

除了上一篇介绍的 使用 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 to ``**xxx-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 分支时，生成预览部署：

name: GitHub Actions Vercel Preview Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches-ignore:
      - main
jobs:
  Deploy-Preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Vercel CLI
        run: npm install --global vercel@canary
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

当代码推送到 main 分支时，生成正式部署：

name: GitHub Actions Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches:
      - main
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Vercel CLI
        run: npm install --global vercel@canary
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

3、借助marketplace 上的 Github Actions 实现

也可以借助一些已经实现好的 actions 来实现我们的需求。比如：

3.1、代码推送或者发起 pull request 时触发

# 可以参考我的工作流
# 定义 GitHub Actions 的工作流程名称
name: Deploy to Vercel

# 触发条件
on:
  push:
    branches: [ main ] # 当代码推送到 main 分支时触发
  pull_request:
    branches: [ main ] # 当针对 main 分支发起 Pull Request 时触发

# 定义工作流程中的作业（jobs）
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: '9.8.0'
      - name: Install Dependencies
        run: pnpm install
      - name: Build
        run: pnpm build
      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          working-directory: ./

3.2、另一例：deploy-to-vercel-action

使用 GitHub Actions 将您的项目/站点部署到Vercel。在何时部署站点方面，它比 Vercel 的 GitHub 集成提供了更多的自定义功能。使用 GitHub Actions Events，您可以选择部署每个提交，仅在新版本上或甚至在 cron 计划上部署。该操作还可以部署每个 PR 并使用自定义预览 URL 对其进行评论。它使用 Vercel CLI，也可以自动在 GitHub 上创建部署。

name: Deploy CI
on:
  push:
    branches: [master]
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  deploy:
    runs-on: ubuntu-latest
    if: "!contains(github.event.head_commit.message, '[skip ci]')"
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to Vercel Action
        uses: BetaHuhn/deploy-to-vercel-action@v1
        with:
          GITHUB_TOKEN: ${{ secrets.GH_PAT }}
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

参考资料

How can I use GitHub Actions with Vercel?

Bring Your Own CI/CD - GitHub Actions** **

使用 Github Action自动执行Vercel 部署

Sun, 16 Mar 2025 00:00:00 GMT

之前本网站部署在 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 官方文档。

官方说的清清楚，部署钩子允许您创建接受 HTTPPOST请求的 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 的示例请求为：

curl -X POST https://api.vercel.com/v1/integrations/deploy/prj_98g22o5YUFVHlKOzj9vKPTyN2SDG/tKybBxqhQs

响应示例：

{
  "job": {
    "id": "okzCd50AIap1O31g0gne",
    "state": "PENDING",
    "createdAt": 1662825789999
  }
}

发送请求后，您可以在项目仪表板上看到它触发了部署。

那么，实现 github actions 代码就比较简单了，参考如下：

name: Trigger Vercel Build
on:
  schedule:
    - cron: '5 0 * * 2' # At 00:05 on 星期二.
  workflow_dispatch:  # 手动触发
jobs:
  build:
    name: Request Vercel Webhook
    runs-on: ubuntu-latest
    steps:
      - name: Curl request
        env:
          VERCEL_BUILD_HOOK: ${{ secrets.VERCEL_BUILD_HOOK }}
        run: curl -X POST $VERCEL_BUILD_HOOK

参考资料

Creating & Triggering Deploy Hooks 官方文档

GitHub Actions：带有输入的调度和计划工作流程

Sat, 15 Mar 2025 00:00:00 GMT

最近编写了一个项目，需要每天定时从 producthunt 抓取数据并生成阅读良好的 markdown 文档，项目已经上线，[参考地址](https://indiehack.org/)。

除此之外，还希望能够输入日期，手动触发抓取这一天的数据。

也就是，工作流有输入。当工作流由 cron 触发时，我需要它使用一些默认变量运行。当手动触发时，我想允许用户覆盖一些默认值。

Github Actions 工作流示例

比如：有如下 github actions 工作流：

name: Print some text every 3rd minute
on:
  schedule:
    - cron: '1/3 * * * *'

jobs:
  print_text:
    runs-on: 'ubuntu-20.04'
    steps:
      -name: Print some text
       run: echo "Periodically printing passages"

每隔一段时间，输出一段文字Periodically printing passages

如果手动触发时，允许输入参数覆盖这一段文字，可以在定义工作流中，使用 inputs 来定义可以接收的输入，参考如下：

name: Print some text every 3rd minute
on:
  schedule:
    - cron: '1/3 * * * *'
  workflow_dispatch: # adding the workflow_dispatch so it can be triggered manually
    inputs:
      text_to_print:
        description: 'What text do you want to print?'
        required: true
        default: 'Periodically printing passages'

jobs:
  print_text:
    runs-on: 'ubuntu-20.04'
    steps:
      - name: Set the variables
        env:
          DEFAULT_MESSAGE: 'Periodically printing passages' # here is the default message
        run: echo "MESSAGE=${{ github.event.inputs.text_to_print || env.DEFAULT_MESSAGE }}" >> $GITHUB_ENV

      - name: Print some text
        run: echo "$MESSAGE" # prints the environmental variable, MESSAGE

我可以在 GitHub 中的 Actions 标签中触发此操作：

让这个工作发挥作用的关键是：

echo "MESSAGE=${{ github.event.inputs.text\_to\_print || env.DEFAULT\_MESSAGE }}" >> $GITHUB\_ENV

上面一行选择将定义的变量赋值给变量，MESSAGE然后将其注入到变量中$GITHUB\_ENV。我们可以在Print some text步骤中引用它。

参考资料