## 简介

[@sidebase/nuxt-auth](https://auth.sidebase.io/) 是一个搭配 `Nuxt3` 使用的项目鉴权插件，其功能是基于 【[Authjs](https://authjs.dev/)】实现的，因此很多配置项与 `Authjs`相同。

> ps: Authjs支持的功能比较多，所以一般都采用 `Authjs` 方案，但 `@sidebase/nuxt-auth` 

## 问题

在使用 `@sidebase/nuxt-auth` 时，需要配置一些基本配置项，可以参考官方文档：https://auth.sidebase.io/guide/authjs/quick-start

其中基础配置项为：

```ts
export default defineNuxtConfig({
  modules: ['@sidebase/nuxt-auth'],
  auth: {
    provider: {
      type: 'authjs',
      trustHost: false,
      defaultProvider: 'github',
      addDefaultCallbackUrl: true
    }
  }
})
```

配置上述内容后，即需要根据 `@sidebase/nuxt-auth` 官方文档编写登录接口，具体内容再次不赘述，有需要可自行查阅。

之后就可以正常启动测试，但是启动时大概率会报错：

```
ℹ AUTH_NO_ORIGIN: No origin - this is an error in production, see https://sidebase.io/nuxt-auth/resources/errors. You can ignore this during development
```

根据这个错误信息可以知道，开发环境可以忽略这个错误，但是如果你看到这里就不管了，生产环境不做处理必然会报错，那么如何解决呢？



## 官方说明

根据错误信息提示打开网址，可以看到关于 `AUTH_NO_ORIGIN` 错误的如下说明：

> `AUTH_NO_ORIGIN` 将在开发期间显示为警告消息，并在生产期间抛出为错误，从而停止应用程序。可以安全地忽略开发警告 - 它只是为您以后的生产部署提供提醒。
> 
> `AUTH_NO_ORIGIN` 当您未设置应用程序的来源时，就会发生这种情况。`NuxtAuth` 会尝试按以下顺序查找应用程序的来源（来源）：
> 
> 1. 环境变量和`runtimeConfig`
> 使用 `AUTH_ORIGIN` 环境变量或（`runtimeConfig.authOrigin`如果已设置）名称可以自定义，请参阅[originEnvKey](https://auth.sidebase.io/guide/application-side/configuration#originenvkey)。
>
> 2. baseURL  
> 根据提供的计算origin得出。请参阅[此处](https://github.com/sidebase/nuxt-auth/blob/9852116a7d3f3be56f6fdc1cba8bdff747c4cbb8/src/runtime/helpers.ts#L9-L23)的实现。
> ```
> export default defineNuxtConfig({
>   auth: {
>     baseURL: `http://localhost:${process.env.PORT || 3000}`
>   }
> })
> ```
> 3. 仅限开发：自动从传入的 `HTTP` 请求中  
> 当服务器以开发模式运行时，`NuxtAuth` 可以从传入的请求中自动推断它。
> 
> 提示：这样做只是为了您的方便 - 请确保在生产中设置正确的原点。
> 
> 如果上述步骤之后仍然无效，`AUTH_NO_ORIGIN` 则生产时会抛出错误。

### 总结

总结一下官方说明，可以通过两种方式配置 `ORIGIN`，如果配置在生产环境无效，则会报错。

## 解决

### 直接环境变量

1. 配置环境变量，如`NUXT_AUTH_ORIGIN`：

```sh
# 生产环境别忘了改
NUXT_AUTH_ORIGIN="http://localhost:9910/api/auth"
```

2. 指定 `origin` 的环境变量 `key`：

在 nuxt 配置文件中增加 `originEnvKey`配置，如：

```ts
export default defineNuxtConfig({
  auth: {
    originEnvKey: 'NUXT_YOUR_ORIGIN'
  },
  runtimeConfig: {
    yourOrigin: ''
  }
})
```

- 补充：本来以为 `AUTH_ORIGIN` 环境变量直接配置，就不用再配置 `originEnvKey` 了，结果发现并不是这么回事，必须配置 `originEnvKey` 才能生效，不知道是老狗打开方式不对还是BUG？。。。

### 配置baseUrl

通过 `auth.baseUrl` 配置项，直接指定url，如果没有单独配置 `origin` 环境变量，则会默认使用 `baseUrl` 为 `origin`。配置如下：

```ts
export default defineNuxtConfig({
  auth: {
    baseURL: https://localhost:3001/api/auth",
  },
})
```

- 补充：`baseUrl` 也可以使用环境变量配置，如：`baseURL: process.env.NUXT_AUTH_ORIGIN`

## 吐槽

这一个配置高这么复杂干嘛，一种方式固定配置得了呗，文档虽然写了这么多，但写 `origin` 这个配置干啥用的至今也没找到相关说明。。。。

使用@sidebase/nuxt-auth开发项目部署时报错AUTH_NO_ORIGIN解决

在 Windows 的 CMD 窗口中，将编码修改为 UTF-8 可以按照以下步骤操作：




## 临时修改

在 `CMD` 窗口中运行以下命令：

```cmd
chcp 65001
```

这会将 `CMD` 的代码页设置为 `UTF-8`（代码页 65001）。设置完成后，CMD 窗口的编码将变为 UTF-8。

> 注意：这种方法是临时的，只对当前 CMD 会话有效。关闭 CMD 窗口后，编码会恢复为默认值。

## 永久修改

如果希望 `CMD` 默认以 `UTF-8` 编码运行，可以通过以下方法设置：

> 修改注册表方案在Windows11中已经失效（`或者操作有误`），再次不做介绍，有兴趣可自己尝试。

在最新的 `Windows10/11` 中，提供了全局修改的方法，但还是测试版本，因此知道的人还不多：

通过 `Win + R` 打开【运行】窗口，输入 `intl.cpl` 点击确定，如下图

![oldmoon.top](https://images.oldmoon.top/images/dingdangdog/1734698865287-1-.jpg)

确定后，将弹出一个窗口，按照如下图中指示修改即可：

![oldmoon.top](https://images.oldmoon.top/images/dingdangdog/1734698514111-1-.jpg)

点击确定后需要重启电脑，使其生效！

> 提示：此方法会将所有 CMD 窗口的默认编码设置为 UTF-8。

Windows修改CMD窗口编码为UTF8 - 最新方案

#### **作用/效果**

该脚本的主要功能是递归处理指定文件夹及其子文件夹中的文件，按照文件名的编码部分（通过空格拆分获取第一个部分）去重，只保留最新创建的文件，并删除重复文件。该功能在文件备份管理中非常有用，能够有效减少冗余文件，节省存储空间。




## Python

需要安装 `Python` 环境！

```python
import os
import shutil

# 指定目标文件夹路径
target_folder = input("请输入目标文件夹路径：")

# 检查文件夹是否存在
if not os.path.exists(target_folder):
    print(f"指定的文件夹 {target_folder} 不存在!")
    exit(1)

# 遍历目标文件夹中的所有文件
for filename in os.listdir(target_folder):
    file_path = os.path.join(target_folder, filename)

    # 确保是文件而不是文件夹
    if os.path.isfile(file_path):
        # 按照'-'分割文件名，取第一个部分作为文件夹名称
        folder_name = filename.split('-')[0]

        # 创建目标文件夹（如果不存在的话）
        folder_path = os.path.join(target_folder, folder_name)
        if not os.path.exists(folder_path):
            os.makedirs(folder_path)

        # 将文件移动到对应的文件夹
        new_file_path = os.path.join(folder_path, filename)
        shutil.move(file_path, new_file_path)

        print(f"文件 {filename} 已移动到 {folder_name} 文件夹")

```

### 运行方式

1. 保存脚本为 `deduplicate.py`。

2. 运行命令：

   ```sh
   python deduplicate.py
   ```

3. 按照提示，输入文件夹，如：

   ```sh
   请输入目标文件夹路径：/path/to/folder
   ```

4. 脚本会自动处理指定文件夹及其所有子文件夹，删除多余文件。

通过该脚本，可轻松实现文件夹中冗余文件的自动化清理工作。


## Nodejs

需要安装Nodejs环境！

```js
const fs = require('fs');
const path = require('path');
const readline = require('readline');

// 创建一个读取用户输入的接口
const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

// 提示用户输入目标文件夹路径
rl.question('请输入目标文件夹路径：', (targetFolder) => {
    // 检查目标文件夹是否存在
    if (!fs.existsSync(targetFolder)) {
        console.error(`指定的文件夹 ${targetFolder} 不存在!`);
        rl.close();
        return;
    }

    // 读取目标文件夹中的所有文件
    fs.readdir(targetFolder, (err, files) => {
        if (err) {
            console.error('读取文件夹内容失败：', err);
            rl.close();
            return;
        }

        files.forEach((filename) => {
            const filePath = path.join(targetFolder, filename);

            // 确保是文件而不是文件夹
            if (fs.lstatSync(filePath).isFile()) {
                // 按照 '-' 分割文件名，取第一个部分作为文件夹名称
                const folderName = filename.split('-')[0];

                // 创建目标文件夹（如果不存在的话）
                const folderPath = path.join(targetFolder, folderName);
                if (!fs.existsSync(folderPath)) {
                    fs.mkdirSync(folderPath);
                }

                // 移动文件到对应的文件夹
                const newFilePath = path.join(folderPath, filename);
                fs.renameSync(filePath, newFilePath);

                console.log(`文件 ${filename} 已移动到 ${folderName} 文件夹`);
            }
        });

        console.log('操作完成!');
        rl.close();
    });
});

```

### 运行方式

1. 保存脚本为 `deduplicate.js`。

2. 运行命令：

   ```sh
   node deduplicate.js
   ```

3. 示例：

   ```sh
   请输入目标文件夹路径：/path/to/folder
   ```

4. 脚本会自动处理指定文件夹及其所有子文件夹，删除多余文件。

通过该脚本，可轻松实现文件夹中冗余文件的自动化清理工作。

## Shell

Linux & MacOS 可直接使用的shell脚本：

```sh
#!/bin/bash

# 提示用户输入目标文件夹路径
read -p "请输入目标文件夹路径: " target_folder

# 检查目标文件夹是否存在
if [ ! -d "$target_folder" ]; then
  echo "指定的文件夹 $target_folder 不存在!"
  exit 1
fi

# 遍历目标文件夹中的所有文件
for file in "$target_folder"/*; do
  # 确保是文件而不是文件夹
  if [ -f "$file" ]; then
    # 获取文件名
    filename=$(basename "$file")
    # 按照 '-' 分割文件名，取第一个部分作为文件夹名称
    folder_name=${filename%%-*}

    # 创建目标文件夹（如果不存在的话）
    folder_path="$target_folder/$folder_name"
    if [ ! -d "$folder_path" ]; then
      mkdir "$folder_path"
    fi

    # 移动文件到对应的文件夹
    mv "$file" "$folder_path"
    echo "文件 $filename 已移动到 $folder_name 文件夹"
  fi
done

echo "操作完成!"

```

文件分组脚本 | Python | Nodejs | Shell

设置 `type` 为 `"commonjs"` 和 `"module"` 的主要区别是决定了你在项目中使用 **模块化语法** 的方式。它们是两种不同的模块化规范，各有特点和适用场景。在 Electron 项目中，这种选择会影响你的代码组织和兼容性。

> PS：下面都是一堆屁话，试用electron强烈推荐使用 `commonjs` 语法，因为使用 `ESM(module)` 语法可能会遇到各种各样奇怪的问题，一旦出现问题比较麻烦！！！

------



## 基本区别

### **CommonJS (`type: "commonjs"`)**

- 规范来源：Node.js 原生支持。
- 语法：
  - 导入模块：`const module = require("module");`
  - 导出模块：`module.exports = someValue;`
- 特点：
  - 模块是同步加载的，代码在运行时加载依赖。
  - 更适合于后端或环境中代码运行时动态加载依赖。

### **ES Module (ESM, `type: "module"`)**

- 规范来源：ECMAScript 标准（现代 JavaScript）。
- 语法：
  - 导入模块：`import module from "module";`
  - 导出模块：`export default someValue;` 或 `export { something };`
- 特点：
  - 模块是静态加载的，代码在编译阶段解析依赖。
  - 提供更高的性能和优化潜力，比如 tree-shaking（移除未使用的代码）。

------

## 优缺点

在 Electron 中，你通常需要写两个部分的代码：

1. **主进程代码**：管理窗口、事件、和操作系统交互（典型文件是 `main.js`）。
2. **渲染进程代码**：与用户界面相关的前端代码（类似普通 Web 应用）。

这两部分可以分别使用 CommonJS 或 ESM，选择的设置主要影响 **主进程** 的代码。

### **CommonJS in Electron**

- **特点**：
  - Electron 的核心 API（如 `require("electron")`）完全兼容 CommonJS。
  - 大量的 Node.js 库原生支持 CommonJS。
  - 更加成熟和广泛使用，适合 Electron 的传统开发模式。
- **优点**：
  - 与现有 Electron 项目和教程兼容，学习曲线低。
  - 不需要调整 Node.js 中原生模块的使用方法。
- **缺点**：
  - 随着 JavaScript 的发展，ESM 正在成为标准规范，CommonJS 在新项目中使用率逐渐下降。
  - 缺少 ESM 的一些高级功能（比如 tree-shaking）。

### **ESM in Electron**

- **特点**：
  - Electron 和 Node.js 现在都支持 ESM，完全可以在项目中使用现代语法。
  - 需要将所有模块改为 `import` 和 `export` 语法。
- **优点**：
  - 使用现代 JavaScript 语法，便于未来维护。
  - 与前端代码统一（渲染进程通常是基于 ESM 的）。
  - 更容易实现性能优化（如 tree-shaking）。
- **缺点**：
  - 如果依赖的库是 CommonJS 格式，需要额外处理（如用 `createRequire` 动态加载）。
  - 部分旧库可能不支持 ESM。

------

## 应用场景

### **选择 `"commonjs"` 的场景**

- 你是初学者，对 JavaScript 和 Electron 生态不熟悉。
- 项目需要大量使用旧的 Node.js 模块或教程。
- 你希望快速实现一个功能原型，不希望花时间调整代码结构。

### **选择 `"module"` 的场景**

- 你想从一开始就使用现代 JavaScript 语法，保持代码的现代化。
- 项目有前后端代码统一为 ESM 的需求。
- 你需要依赖一些现代的 ESM-only 的库（如 `node-fetch@3`）。

------

## 如何选择和使用

### **保持 CommonJS**

1. `package.json`:

   ```
   json复制代码{
     "type": "commonjs"
   }
   ```

2. 主进程代码（`main.js`）：

   ```
   javascript复制代码const { app, BrowserWindow } = require("electron");
   
   app.whenReady().then(() => {
     const win = new BrowserWindow();
     win.loadFile("index.html");
   });
   ```

3. 优化点：

   - 如果需要 ESM-only 的库（如 

     ```
     node-fetch@3
     ```

     ），用 

     ```
     dynamic import
     ```

     ：

     ```
     javascript复制代码const fetchData = async () => {
       const { default: fetch } = await import("node-fetch");
       const data = await fetch("https://api.example.com").then((res) => res.json());
       console.log(data);
     };
     ```

### **迁移到 ESM**

1. `package.json`:

   ```
   json复制代码{
     "type": "module"
   }
   ```

2. 主进程代码（`main.js`）：

   ```
   javascript复制代码import { app, BrowserWindow } from "electron";
   
   app.whenReady().then(() => {
     const win = new BrowserWindow();
     win.loadFile("index.html");
   });
   ```

3. 如果依赖 CommonJS 库，使用 `createRequire`：

   ```
   javascript复制代码import { createRequire } from "module";
   const require = createRequire(import.meta.url);
   const fs = require("fs"); // 加载 CommonJS 模块
   ```

------

## 总结

- 如果你是初学者，并且希望快速开始，**选择 CommonJS (`type: "commonjs"`)**。这能让你避免一些兼容性问题，同时与大部分 Electron 教程一致。
- 如果你希望项目与现代 JavaScript 保持一致并长期维护，**选择 ESM (`type: "module"`)**，尤其是当你已经熟悉了 ESM 语法和工具。

两种方式都可以用在 Electron 项目中，选择适合你当前需求和学习阶段的即可。

Electron项目中，应该使用commonjs还是module？

## 问题简介

如题，使用 `ElementUI` 开发的网页(包括 `ElementPlus`)，在 `Safari` 浏览器中，列表往往会出现一些不美观的效果，如：

- 内容过长，但设置隐藏不起效；
- 表头与数据列不对齐；
- 固定列无效等等。

该问题是由于 `Element` 对 `Safari` 的适配没有做的很完善，并且该问题也是个历史性的老问题了，截至本文记录，该问题至少已经经过了 6 年，但仍然未解决。

> 详情可见：https://github.com/ElemeFE/element/issues/10308



## 解决办法

根据用户反馈，临时解决办法是手动覆盖一些 `Element` 默认的css样式，如全局引用以下css：

```css
.el-table table {
  width: 0 !important;
  table-layout: fixed !important;
}

.el-table .el-table__body {
  width: 0 !important;
  table-layout: fixed !important;
}
```

ElementUI的列表（table）再ios浏览器（safari）中表头错位问题记录【附临时解决办法】

twitter:card

twitter:title

twitter:site

twitter:image

努力做一只帅气、有才、豁达的老狗！

twitter:description

程序员,笔记,Bug记录,编程技术,AI,Java,Node,Golang,个人博客,资源分享,月上老狗,dingdangdog