> 因为最近在准备面试，简历里贴了我这个网站，所以在这里快速介绍一些简历里技术之外的细节

> 【4月14日更新】已入职新工作，暂时不考虑新机会





00年，全日制统招本科，计算机科学与技术专业

## 社区

在社区很活跃，除了在上家公司996+封闭开发的时候...

**CSDN（2w粉）【学习、总结能力还行】：** https://blog.csdn.net/m0_46171043?spm=1000.2115.3001.5343

还在上学的时候，就在CSDN开始写东西，本来只是单纯找个地方归纳总结自己的学习过程，不知不觉也有几万粉丝了。

**B站（5k粉）【表达能力还行】：** https://space.bilibili.com/416065222?spm_id_from=333.1007.0.0

在没事的时候就喜欢找个事做，在B站陆续更新了几个小程序相关项目的教程，主要服务群体是那些刚入门的。

**微信公众号（7k粉）：**

公众号写的就比较杂了，什么都写点。

![qrcode_for_gh_fe6e92caacd9_258.jpg](https://creatorblog.cn/static/img/9cfb252e1c0b6b096e1d98686950925d.qrcode_for_gh_fe6e92caacd9_258.webp)


## 工作经历

工作经历就由近到远吧，半年 + 两年多 + 半年，三年左右的前端工作经验

### 北京细红线科技有限公司（AI应用 + 软硬件结合 + 跨平台）

24年中旬进入了第二家公司，[**北京细红线科技有限公司**](https://matter.ai/) **罗永浩**宣布的 "最后一次" 创业的公司，做的是一个AI应用类的项目，软件＋硬件。软件是跨平台的，Android + IOS + Webapp + Electron，Android和IOS由专门的Flutter团队维护，前端维护Web和Electron桌面端。

因为主推的是移动端的App，所以前端的方案其实是 "备胎"，管理层觉得在某些时候，应用商店会下架他们Android和IOS的应用，到时候需要一个备选方案，所以前端就1：1复刻做了Webapp，在浏览器运行的项目。

这也是后续被裁的最主要原因，因为各种各种各种原因，导致项目的发布会一直没开，所以主推的移动端App一直难产，我们这种极其特殊情况下的前端备选方案就肯定会先被干掉了。

一共工作了6个月，24年12月31号被裁了。

**薪资：18k 15薪**

**技术栈：React + TypeScript + TailwindCSS + Electron + MQTT**

### 北京北极狐信息科技有限公司（Apipost、RunnerGo）

22年中旬毕业后参加第一份正式公司， [**北京北极狐信息科技有限公司**](https://www.runnergo.com/) 可能这家公司知名的产品是 **Apipost** , 我进去的时候，公司要做另一个产品 **RunnerGo** ，在开始的一年半的时间里，前端只有我一个，从0搭建起了这个项目。

因为刚毕业当时举步维艰，有个很难做的模块：API拖拽可视化的场景。


![image.png](https://creatorblog.cn/static/img/3737ee219a75b01b722c33811d26fbe2.image.webp)


陆续干了两年多，后续因为Boss要我换去其它项目，分给了我一些看似不可能做完的事情（时间不够）。给了我一种要借机干掉我的感觉，当时已经完全度过了早期艰难的阶段，**RunnerGo** 这个项目也进入稳定迭代的时间，就主动离职了。【我离职了没两个月，这个项目就把人裁完了... 】

因为当时有维护主项目React，社区项目Vue，官方原生，所有技术栈比较杂

**薪资：刚进去14k，干了半年HR主要找我涨了2k，所以大部分时间都是16k**

**技术栈：React + React-Flow + Vue + WebSocket + Sass**

### 北京旷视科技有限公司（国内早期的AI四小龙）

21年开始参加实习，在[ **北京旷视科技有限公司** ](https://www.megvii.com/) 实习了半年多。负责了两个产品线的迭代，大模型生产平台AIS、算法量产小程序。当时ChatGPT还没出现，国内有知名度做AI的只有旷视在内的四小龙。

这个大模型生产平台类似于一个管理系统，可以通过界面级的操作，快速的创建和训练模块。

这个算法量产小程序，就是针对具体的算法能力，进行功能级的产出，有图像修改（比如拍了一个人脸，给改成微笑、愤怒）、一句话生成一个图片（最早的文生图）

**薪资：因为是实习按天算的，好像200左右一天吧**

**技术栈：Vue2 + TypeScript + Stylus + 微信小程序**

个人介绍

> 现在越来越多的公司在做出海项目，出海项目首先要解决的就是语言国际化的问题，有很多如l18n、l10n的工具可以用，这些工具可以提供解决方案，但是不能约束开发者的开发行为。开发者仍然可能在代码中存留没有做过国际化处理的部分，假设后续 MR 的Code Review也没有查出来，这就是很大的隐患了，甚至会有监管风险，因为很多项目不想让别人知道是中国团队做的，所以要严格禁止控制台输出中文日志。




我最近也是接到一个这样的需求，本来需求是让我人肉检查一下项目中有没有输出中文日志的情况。人肉是不可能人肉的，我觉得这个可以通过写脚本来实现检查，因为核心要素其实就两个点：

1. 需要检查中文
2. 需要全局检查所有文件

这些要素都可以通过 `Node.js` 脚本来实现。

这个脚本会实现以下能力：

1. 读取当前项目下所有目录、所有文件
2. 能有效检查文件中是否包含中文字符
3. 可以提前声明要忽略的文件夹/文件
4. 主动忽略所有注释，包含`//`、`/* ... */`、`{/* ... */}`
5. 输出详细的检查结果日志，包含 文件路径、文件行数、相关代码，并且高亮检查出来的中文的部分



![image.png](https://creatorblog.cn/static/img/465e62d8bbeca977021cb591608c07ca.image.webp)



在项目根目录新建一个文件，如`check-chinese.js`。写入以下内容：

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

// 中文字符的正则表达式
const chineseRegex = /[\u4e00-\u9fa5]/;

// 要忽略的文件或目录
const ignorePatterns = [
  'node_modules',
  '.git',
  '.next',
  'public',
  'locales',
  'dist',
  'build',
  'check-chinese'
];

// 要检查的文件扩展名
const extensions = ['.ts', '.tsx', '.js', '.jsx'];

// 控制台颜色
const colors = {
  reset: '\x1b[0m',
  bright: '\x1b[1m',
  dim: '\x1b[2m',
  underscore: '\x1b[4m',
  blink: '\x1b[5m',
  reverse: '\x1b[7m',
  hidden: '\x1b[8m',
  
  black: '\x1b[30m',
  red: '\x1b[31m',
  green: '\x1b[32m',
  yellow: '\x1b[33m',
  blue: '\x1b[34m',
  magenta: '\x1b[35m',
  cyan: '\x1b[36m',
  white: '\x1b[37m',
  
  bgBlack: '\x1b[40m',
  bgRed: '\x1b[41m',
  bgGreen: '\x1b[42m',
  bgYellow: '\x1b[43m',
  bgBlue: '\x1b[44m',
  bgMagenta: '\x1b[45m',
  bgCyan: '\x1b[46m',
  bgWhite: '\x1b[47m'
};

// 使用第三方库来解析代码和注释
function parseFileContent(content, filePath) {
  // 首先通过简单的方式移除所有注释
  let processedContent = content;
  
  // 1. 移除多行注释 /* ... */
  processedContent = processedContent.replace(/\/\*[\s\S]*?\*\//g, match => {
    // 保留换行符以保持行号
    return match.replace(/[^\n\r]/g, ' ');
  });
  
  // 2. 移除单行注释 // ...
  processedContent = processedContent.replace(/\/\/.*$/gm, match => {
    // 保留相同长度的空格
    return ' '.repeat(match.length);
  });
  
  // 3. 移除JSX注释 {/* ... */}
  processedContent = processedContent.replace(/\{\/\*[\s\S]*?\*\/\}/g, match => {
    // 保留换行符以保持行号
    return match.replace(/[^\n\r]/g, ' ');
  });
  
  return processedContent;
}

// 检查文件中的中文字符
function checkFileForChinese(filePath) {
  try {
    const content = fs.readFileSync(filePath, 'utf8');
    
    // 处理文件内容，移除注释
    const processedContent = parseFileContent(content, filePath);
    
    // 按行检查处理后的内容
    const lines = processedContent.split('\n');
    const originalLines = content.split('\n');
    
    const results = [];
    
    lines.forEach((line, index) => {
      // 检查行中是否包含中文字符
      if (chineseRegex.test(line)) {
        results.push({
          file: filePath,
          line: index + 1,
          content: originalLines[index].trim()
        });
      }
    });
    
    return results;
  } catch (error) {
    console.error(`${colors.red}无法读取文件 ${filePath}: ${error.message}${colors.reset}`);
    return [];
  }
}

// 递归遍历目录
function traverseDirectory(dir) {
  const results = [];
  
  try {
    const files = fs.readdirSync(dir, { withFileTypes: true });
    
    for (const file of files) {
      const fullPath = path.join(dir, file.name);
      
      // 检查是否应该忽略此路径
      if (ignorePatterns.some(pattern => fullPath.includes(pattern))) {
        continue;
      }
      
      if (file.isDirectory()) {
        results.push(...traverseDirectory(fullPath));
      } else if (file.isFile() && extensions.includes(path.extname(file.name))) {
        results.push(...checkFileForChinese(fullPath));
      }
    }
  } catch (error) {
    console.error(`${colors.red}无法读取目录 ${dir}: ${error.message}${colors.reset}`);
  }
  
  return results;
}

// 高亮显示中文字符
function highlightChinese(text) {
  return text.replace(/([\u4e00-\u9fa5]+)/g, `${colors.bgYellow}${colors.black}$1${colors.reset}`);
}

// 主函数
function main() {
  console.log(`${colors.cyan}${colors.bright}=== 开始扫描中文字符... ===${colors.reset}`);
  
  const results = traverseDirectory('.');
  
  if (results.length === 0) {
    console.log(`${colors.green}${colors.bright}✓ 没有找到非注释中的中文字符！${colors.reset}`);
  } else {
    console.log(`${colors.yellow}${colors.bright}! 找到 ${results.length} 处可能需要国际化的中文字符：${colors.reset}\n`);
    
    // 按文件分组
    const fileGroups = {};
    results.forEach(result => {
      if (!fileGroups[result.file]) {
        fileGroups[result.file] = [];
      }
      fileGroups[result.file].push(result);
    });
    
    // 输出分组结果
    Object.keys(fileGroups).forEach(file => {
      console.log(`${colors.blue}${colors.bright}文件: ${file}${colors.reset}`);
      fileGroups[file].forEach(result => {
        console.log(`  ${colors.magenta}行 ${result.line}:${colors.reset} ${highlightChinese(result.content)}`);
      });
      console.log(''); // 空行分隔不同文件
    });
    
    console.log(`${colors.yellow}${colors.bright}请检查上述中文字符，并考虑使用国际化方案替换它们。${colors.reset}`);
  }
}

// 执行主函数
main();

```

然后通过`node ./check-chinese.js`来执行脚本

也可以在`package.json`中新增一个`scripts`

```json
{
   ...
  "scripts": {
    ...
    "check-chinese": "node ./check-chinese.js"
  },
}
```

然后通过`npm run check-chinese`来执行脚本

通过脚本自动检查项目中的中文

> 大多数团队都会要求不能在生产环境输出业务侧的内容，但是往往业务开发人员会有疏漏，所以需要在工程化环境中，整体来管理console.log。我最近也是接到这样一个需求，整理了一下实现方案。




不同团队，不同场景，不同风格中，移除生产环境`console.log`的方案众多，我以 `Nextjs` 项目为背景介绍几种主流的，基本都是通用方案。

## 配置next.config.js

如果你使用的是 Next.js 13或者更高版本（使用SWC编译器），可以在`next.config.js`中这样配置

```js
const nextConfig = {
  compiler: {
    removeConsole: process.env.NODE_ENV === 'production'
}
```

如果要保留部分`console`方法，比如`warn`和`error`，可以这样写

```js
const nextConfig = {
  compiler: {
    removeConsole: process.env.NODE_ENV === 'production' ? {
      exclude: ['error', 'warn']
    } : undefined
  }
}
```

## 使用Babel插件

可以使用`babel-plugin-transform-remove-console`插件在构建时自动移除所有`console`语句。

1. 安装插件

```bash
npm install babel-plugin-transform-remove-console --save-dev
```

2. 在项目根目录创建或修改`.babelrc`文件：

```json
{
  "presets": ["next/babel"],
  "env": {
    "production": {
      "plugins": ["transform-remove-console"]
    }
  }
}

```
这样配置后，只有在生产环境构建时才会移除`console`语句。

## 重写console对象

通过重写`console`对象来实现移除`console.log`是一种可行的方案。这种方法的核心思想是在运行时替换原生`console`对象的方法。

```js
if (process.env.NODE_ENV === 'production') {
  // 重写console.log方法为空函数
  console.log = () => {};
}
```

写在项目的入口文件中，如果使用`Nextjs`的`App Router`，可以写在`app/layout.tsx`中


## 使用ESLint规则

可以使用`ESLint`来在开发过程中提示或禁止使用`console`语句。

1. 确保已安装`ESLint`：

```bash
npm install eslint --save-dev
```

2. 在`.eslintrc.js`文件中添加规则：

```js
module.exports = {
  // 其他配置...
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'warn',
  },
};
```

## 使用TypeScript编译选项

如果项目有用到`TypeScript`，可以利用`TypeScript`的编译选项来移除`console`语句。

在`tsconfig.json`中添加以下配置：

```json
{
  "compilerOptions": {
    // 其他配置...
    "removeComments": true,
    "stripInternal": true
  }
}
```

## 自定义日志工具

创建一个自定义的日志工具，可以根据环境变量决定是否输出日志。

```js
// utils/logger.ts
const logger = {
  log: (...args: any[]) => {
    if (process.env.NODE_ENV !== 'production') {
      console.log(...args);
    }
  },
  error: (...args: any[]) => {
    // 错误日志在生产环境中也可能需要保留
    console.error(...args);
  },
  // 其他日志方法...
};

export default logger;
```

然后在项目中使用`logger.log()`替代`console.log()`。

## 总结

综合看，如果你使用的是`Nextjs` 13+的版本，通过配置`next.config.js`来实现是最优解，其它情况更推荐`Babel`插件的方案

`Babel`方案的优势：

1. 在编译时自动处理，不需要手动修改代码，`console.log`调用完全从`bundle`中移除
2. 只在生产环境中移除`console`语句，开发环境保持不变
3. 实现简单，配置一次即可
4. 不依赖框架环境

移除生产环境所有console.log

> 在 React 中，​受控组件（Controlled Components）​ 和 ​非受控组件（Uncontrolled Components）​ 是处理表单元素的两种不同方式，它们的核心区别在于 ​数据管理的方式 和 ​与 React 的交互模式。




# 受控组件（Controlled Components）

## 定义

表单元素（如 `<input>`、`<textarea>`、`<select>`）的值由 ​`React` 的 `state` 完全控制。用户输入会触发 `React` 的状态更新，表单的当前值始终与 `React` 的 `state` 同步。

## 关键特征

- 数据流：单向绑定（从 React state 到 DOM）。
- 更新方式：通过 onChange 事件手动更新 state。
- 值的来源：组件的 value 或 checked 属性直接绑定到 state。

## 代码示例

```jsx
import { useState } from 'react';

function ControlledForm() {
  const [inputValue, setInputValue] = useState('');

  const handleChange = (e) => {
    setInputValue(e.target.value); // 手动同步到 state
  };

  return (
    <input
      type="text"
      value={inputValue} // 值由 React state 控制
      onChange={handleChange}
    />
  );
}
```

## 适用场景

- 需要实时验证输入（如密码强度检查）。
- 动态表单（如根据输入内容显示其他字段）。
- 强制输入格式（如只能输入数字）。

## 优点

- 完全控制表单数据，确保 React state 是唯一数据源。
- 支持复杂的交互逻辑（如输入时实时反馈）。

## 缺点

- 代码量较多（需要为每个表单元素编写事件处理函数）。
- 频繁的 state 更新可能导致性能问题（大型表单需优化）。

# 非受控组件（Uncontrolled Components）

## 定义

表单元素的值由 ​`DOM` 自身管理，`React` 通过 `ref` 在需要时（如表单提交时）直接读取 `DOM` 的值。用户输入不会触发 `React` 的状态更新。

## 关键特征

- 数据流：直接操作 DOM。
- 更新方式：通过 ref 手动获取值。
- 值的来源：DOM 节点的当前值。

## 代码示例

```jsx
import { useRef } from 'react';

function UncontrolledForm() {
  const inputRef = useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log(inputRef.current.value); // 通过 ref 获取 DOM 值
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        ref={inputRef} // 使用 ref 关联 DOM 节点
        defaultValue="初始值" // 仅初始化时设置默认值
      />
      <button type="submit">提交</button>
    </form>
  );
}
```

## 适用场景

- 简单表单（不需要实时验证或动态交互）。
- 文件上传（`<input type="file">` 必须用非受控组件）。
- 性能敏感场景（避免频繁 state 更新）。

## 优点

- 代码简洁，无需管理状态。
- 性能更好（减少渲染次数）。

## 缺点

- 无法实时控制数据（如强制输入格式）。
- 不符合 React 的“单一数据源”原则。

# 核心区别对比


| 特性 | 受控组件 | 非受控组件 | 
| --- | --- | --- |
| **数据管理** | React state 控制  | DOM 自身管理 |
| **值同步** | 实时同步（onChange 事件） | 手动获取（通过 ref） |
| ​**初始值设置** | 通过 value 属性 | 通过 defaultValue 属性 |
| **表单验证时机** | 输入时实时验证 | 提交时验证 |
| **代码复杂度** | 较高（需处理事件和状态） | 较低（直接操作 DOM） |
| **性能** | 可能较低（频繁渲染） | 较高 |
| **React 哲学匹配度** | 高（符合单向数据流） | 低（依赖 DOM 操作）|

# 如何选择

1. **优先受控组件：**

大多数场景推荐使用受控组件，尤其是需要实时交互、验证或动态表单时。

2. **非受控组件的合理场景：**

- 文件上传（`<input type="file">`）。
- 性能敏感且无需实时反馈的表单。
- 与非 React 的第三方库集成（如富文本编辑器）。

# 注意点

1. **文件输入**：

`<input type="file">` 必须用非受控组件，因为其值只能由用户设置（安全限制）。

2. **默认值：**

非受控组件用 `defaultValue` 或 `defaultChecked` 设置初始值（类似原生 `HTML`）。

3. **受控组件的性能优化：**

大型表单中避免频繁渲染，可通过防抖（`debounce`）或 `useCallback` 优化事件处理函数。

# 总结

- ​受控组件：数据由 React 完全控制，适合复杂交互。
- 非受控组件：数据由 DOM 管理，适合简单场景或性能敏感需求。

根据实际需求选择，优先遵循 `React` 的单向数据流原则，仅在必要时使用非受控组件。

受控组件和非受控组件的区别

> 前端项目中，路由设计是重中之重，常见的路由模式基本有三种，适合在不同场景下进行选择。本文针对React项目的React Router API进行示例。




在 `React` 项目中，路由模式主要取决于使用的路由库（如 `React Router`）和部署环境的需求。以下是 `React` 应用中常见的三种路由模式及其核心区别：


# BrowserRouter（History 模式）

- URL 格式：

`https://example.com/path/to/page`

- 原理：

用 `HTML5` 的 `history.pushState` API，动态修改 `URL` 路径而不刷新页面。

- 特点：
    - URL 无 # 符号，更简洁友好。
    - 需要服务器配合（如配置重定向规则），否则直接访问子路由会返回 404。

- 适用场景：
    - 需要 SEO 优化的项目（对搜索引擎友好）。
    - 服务端渲染（SSR）或静态站点生成（SSG）的应用。

- 配置示例：

```jsx
import { BrowserRouter } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      {/* 路由配置 */}
    </BrowserRouter>
  );
}
```

# HashRouter（Hash 模式）

- URL 格式：

`https://example.com/#/path/to/page`

- 原理：

利用 `URL` 的 `hash` 部分（# 后的内容）实现路由，通过监听 `hashchange` 事件更新页面。

- 特点：
    - `URL` 包含 #，兼容性更好。
    - 无需服务器配置，适合静态托管（如 GitHub Pages）。
    - 对搜索引擎不友好（部分爬虫会忽略 # 后的内容）。

- 适用场景：
    - 纯前端静态托管项目。
    - 旧版浏览器兼容性要求较高的场景。

- 配置示例：

```jsx
import { HashRouter } from 'react-router-dom';

function App() {
  return (
    <HashRouter>
      {/* 路由配置 */}
    </HashRouter>
  );
}
```

# MemoryRouter（内存路由模式）

- URL 格式：

无实际 `URL` 变化，路由状态保存在内存中。

- 原理：

不依赖浏览器 URL，适用于非浏览器环境（如 `React Native`、测试环境）。

- 特点：
    - 无地址栏交互，适合嵌入式应用或需要隐藏路由的场景。
    - 路由状态仅在内存中维护，刷新页面会丢失。

- 适用场景：
    - 非浏览器环境（如移动端应用、单元测试）。
    - 需要完全控制路由行为的场景。

- 配置示例：

```jsx
import { MemoryRouter } from 'react-router-dom';

function App() {
  return (
    <MemoryRouter>
      {/* 路由配置 */}
    </MemoryRouter>
  );
}
```

# 路由模式对比表


| 模式 | BrowserRouter | HashRouter | MemoryRouter |
| --- | --- | --- | --- |
| **URL 格式**  | 无 # | 有 # | 无 URL 变化 |
| **服务器需求** | 需配置重定向 | 无需配置 | 无 |
| **SEO 友好性** | 高 | 低 | 无 |
| **兼容性** | 需支持 HTML5 History API | 兼容所有浏览器 | 所有环境 |
| **典型场景** | 生产环境、SSR/SSG | 静态托管、旧浏览器 | 测试、React Native |

# 如何选择路由模式

1. BrowserRouter：

- 优先选择，适合现代 Web 应用。
- 部署时需配置服务器（如 Nginx/Apache 的 try_files 或 rewrite 规则）。

2. HashRouter：

- 用于静态托管或兼容性要求高的场景。
- 避免 SEO 敏感型项目。

3. MemoryRouter：

- 仅在非浏览器环境或特殊需求时使用。

# 服务器配置示例（BrowserRouter）

若使用 `BrowserRouter`，需确保服务器将所有路径重定向到 `index.html`：

- Nginx：

```nginx
location / {
  try_files $uri $uri/ /index.html;
}
```

- Apache：

```apache

RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

```


# 总结

常见的路由模式可以分为三类：History模式、Hash模式、Memory模式，通过合理选择路由模式，可以平衡开发体验、用户友好性和部署复杂性，Vue项目的Vue Router也有对等的API，都是一样的。

React项目的三种路由模式

欢迎来到我的博客，这里是我分享前端、web3、理财、互联网等方面的知识和心得的地方。我是一名热爱编程的前端程序员，我希望通过我的博客能够帮助更多的人学习和进步。在这里，你可以找到最新最实用的前端技术教程，了解最前沿的互联网动态和趋势，掌握最有效的理财方法和策略。我也会不定期地发布一些个人项目和作品，展示我的创意和能力。如果你对我的博客感兴趣，欢迎你留言、评论、收藏、关注，也可以通过邮箱或社交媒体与我联系，交流学习和合作。谢谢你的支持！