本文介绍了前端开发中 Git 版本控制的实用技巧。涵盖初始化、分支管理、提交规范、常见坑点及解决方案。详细讲解了 Feature Branch 和 Git Flow 策略，Conventional Commits 规范，以及 Husky Hooks 自动化流程。同时提供了 .gitignore 配置清单、多人协作守则、回滚急救方法及针对 JavaScript 项目的优化建议，帮助开发者高效管理代码并避免团队协作中的常见问题。
说实话，刚入行时对 Git 的态度就像对待总唠叨的亲戚——觉得麻烦，能躲就躲。记得有次熬夜写了个轮播图，第二天手一抖把文件夹拖进回收站还清空了。那一刻坐在电脑前，感觉世界安静了，只剩下风扇转动的声音。
后来进了团队，情况更魔幻。队友改了我写的工具函数没吱声，我这边一拉代码，整个项目直接红成一片。直到被老大摁着头学 Git，我才慢慢反应过来：这玩意儿根本不是啥"高级工具"，它就是前端人的记事本、后悔药、甚至是护身符。
所以今天不整虚的，聊聊 JavaScript 开发里 Git 到底该怎么用才能真香。不是那种"git add . git commit -m"的流水账，而是实打实的踩坑实录和救命技巧。
很多人以为 Git 就是"提交 - 推送"那两下子，跟用网盘似的。错！这么想的话，你就亏大了。
现在前端啥情况？组件化、模块化、微前端、Monorepo……一个项目里可能同时跑着 React、Vue、Node 脚本，还有一堆配置文件。你改个 Button 组件，说不定会影响到十个页面；你升级个依赖，可能整个构建流程就崩了。没个靠谱的版本控制，这项目分分钟变成"祖传屎山"——你都不敢动，生怕一动就塌。
Git 最牛逼的地方在于它是你的时光机。你随时可以回到"昨天下午三点那个还能跑的版本"，或者看看"上周是谁把那个判断条件写反了"。更重要的是，它是协作翻译官。你写你的 feature 分支，我写我的 bugfix 分支，最后通过 PR（Pull Request）合到主干，中间还能互相 review 代码。这就好比两个人同时改一份 Word 文档，但不会出现"你覆盖我、我覆盖你"的血案。
而且啊，现在的 CI/CD（持续集成/持续部署）都是跟 Git 绑定的。你 push 代码到特定分支，自动跑测试、自动构建、自动部署。Git 提交信息写规范了，连版本号都能自动生成。这哪是版本控制，这是你的自动化流水线开关。
咱前端每天打开项目，第一件事通常是 git pull，看看队友又整了啥新活儿。然后开始写代码，写完了 git add，git commit，git push，一套组合拳打完，代码就上云了。听起来简单，但魔鬼藏在细节里。
新项目启动，别急着写代码，先把 Git 仓库建好：
# 初始化仓库，这会在项目根目录生成.git 文件夹
git init
# 或者直接从远程克隆现成的
git clone https://github.com/你的项目.git
然后马上搞 .gitignore 文件，这玩意儿太重要了。前端项目里 node_modules 动辄几万文件，你不忽略掉，Git 会疯，你也会疯。
写新功能？别在 main 或 master 分支上直接撸代码，那是找死。规矩是：新建 feature 分支，改完再合并。
# 基于当前分支创建并切换到新分支
git checkout -b feature/awesome-carousel
# 或者新版 Git 的命令，更直观
git switch -c feature/awesome-carousel
分支命名也有讲究。别叫 test、fix、111 这种让人摸不着头脑的名字。推荐用 feature/功能描述、bugfix/问题描述、hotfix/紧急修复 这种格式。队友一看分支名就知道你在干啥，省得来回问。
很多人有个坏习惯：写了一天代码，晚上一次性提交，commit 信息就写个"update"。这不行！Git 的提交应该小而频繁，每个 commit 只做一件事。
比如你在做用户登录功能：
这样好处太多了。如果后面发现 API 对接有问题，你可以只回滚第三次提交，前两次的 UI 和验证逻辑还在。如果揉成一个 commit，那就得全回滚，UI 也没了。
# 查看当前修改了哪些文件
git status
# 选择性添加，别直接 git add .
git add src/components/LoginForm.jsx
git add src/utils/validation.js
# 提交，信息写清楚
git commit -m "feat: 添加登录表单的基础验证逻辑 - 实现邮箱格式校验 - 添加密码长度限制（6-20 位） - 错误提示文案优化"
看到没，commit 信息里我还加了详细描述。用空行隔开标题和正文，这是 Git 的规范。队友看 git log 的时候，一眼就能明白这次改动做了啥，为啥做。
说到踩坑，那我可太有发言权了。Git 这玩意儿，用好了是神器，用不好就是埋雷。咱一条条拆开说，都是血泪换来的经验。
"fix bug"、"update"、"111"、"test"……这种提交信息，三天后你自己都看不懂，更别说队友了。最尴尬的是，线上出问题了，你要找哪次提交引入的 bug，结果对着满屏的"update"欲哭无泪。
正确姿势：用Conventional Commits规范。简单说，就是给 commit 加个类型前缀：
# 新功能
git commit -m "feat: 添加商品购物车组件"
# 修复 bug
git commit -m "fix: 修复 iOS 下日期选择器无法弹出的问题"
# 文档更新
git commit -m "docs: 更新 API 接口文档"
# 代码重构（不改功能只优化结构）
git commit -m "refactor: 抽离表单验证逻辑到独立模块"
# 样式调整
git commit -m "style: 调整移动端导航栏间距"
# 测试相关
git commit -m "test: 添加用户登录流程的单元测试"
# 构建或工具链
git commit -m "chore: 升级 webpack 到 5.x 版本"
这规范的好处是，配合工具可以自动生成 CHANGELOG，甚至自动打版本号。比如 feat 开头的是次要版本，fix 开头的是补丁版本。CI/CD 流水线里常用这个。
这种情况多发生在团队协作初期。你 pull 代码，发现有冲突，Git 在文件里标了 <<<<<<< HEAD 这种符号。新手一看，慌了，直接删掉别人的部分，只留自己的，然后提交了。
结果呢？队友的代码没了，功能崩了，你们俩还得吵架。其实冲突标记长这样：
<<<<<<<HEAD
// 你当前的代码
const apiUrl ='https://api.old.com';
=======
// 别人改的代码
const apiUrl ='https://api.new.com';
>>>>>>> feature/new-api-endpoint
正确姿势：仔细看两边的代码，理解别人为啥这么改。如果确定要保留某一边，可以用 Git 命令：
# 保留当前分支的版本
git checkout --ours src/config/api.js
# 保留合并进来的版本
git checkout --theirs src/config/api.js
# 或者手动编辑文件，删掉冲突标记后
git add src/config/api.js
git commit -m "merge: 解决 api 地址配置冲突，采用新域名"
实在拿不准，停下来，去问写那段代码的人。别瞎猜，这是团队协作的基本礼貌。
这是最要命的。你把数据库密码、API 密钥、阿里云 OSS 的 secret，直接写代码里，然后 push 到 GitHub。哪怕后面删了，提交记录里还在，黑客一翻 commit history 就能找到。
我就见过一个案例，某创业公司的 AWS 密钥泄露在 GitHub 上，第二天账户就被刷了上万美金，全是挖矿实例。
正确姿势：用 .env 文件和环境变量。前端项目里：
// .env 文件（这个要加入.gitignore！！！）
REACT_APP_API_KEY=your_secret_key_here
REACT_APP_API_URL=https://api.example.com
// 代码里这样用
const apiKey = process.env.REACT_APP_API_KEY;
如果不小心已经 push 了敏感信息，别只删文件，要用 git filter-branch 或 BFG Repo-Cleaner 清理历史记录。然后立即更换密钥，因为 GitHub 有爬虫专门扫这些。
# 用 BFG 清理（需要 java 环境）
java -jar bfg.jar --replace-text passwords.txt my-repo.git
# 或者 git 原生命令（慎用，会重写历史）
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch 配置文件.js' --prune-empty --tag-name-filter cat -- --all
这个习惯不改，迟早出事。main 分支应该是永远可部署的稳定版本。你直接在上面改，万一改崩了，整个团队都跑不起来。
正确姿势：强制用分支工作流。哪怕改个标点符号，也给我新建分支：
# 从 main 切出来
git checkout main
git pull origin main
git checkout -b fix/typo-in-readme
# 改完提交
git add README.md
git commit -m "docs: 修复 README 中的拼写错误"
# push 到远程
git push origin fix/typo-in-readme
# 然后去 GitHub/GitLab 提 PR，让队友 review 后再合并
网上讲 Git Flow、GitHub Flow、GitLab Flow 的文章一大堆，看得人头大。其实对大多数前端项目，特别是中小型团队，真没必要搞那么复杂。
这是最适合前端团队的策略，简单粗暴：
# 功能开发完整流程
git checkout main
git pull origin main
git checkout -b feature/user-profile-page
# 写代码……写代码……写代码
git add .
git commit -m "feat: 完成用户个人中心页面基础功能"
git push origin feature/user-profile-page
# 然后去 GitHub 提 PR，设置 reviewer，等 approve 后合并
如果你的项目需要严格区分开发版、预发版、生产版，比如有 develop 分支做集成测试，release 分支做上线准备，那可以用 Git Flow。但说实话，现在有了 CI/CD 和容器化，很多团队已经简化掉了。
最怕的是团队里有人用 Git Flow，有人用 GitHub Flow，还有人直接在 main 上 push。那场面，想想都酸爽。所以团队一开始就要定规矩，写在 CONTRIBUTING.md 里，新人入职先读这个。
前面提到了 Conventional Commits，这里再展开说说怎么写得像人话，而不是机器生成的。
# 差的例子
git commit -m "fix bug"
# 好的例子
git commit -m "fix(auth): 修复 token 过期后未自动跳转登录页的问题 问题描述：用户保持页面打开超过 2 小时后，token 失效但页面仍显示已登录状态，点击任何需要鉴权的操作都会报错，体验很差。解决方案：- 在 axios 拦截器中添加 401 状态码监听 - 检测到 401 后清除本地存储的 token 并跳转登录页 - 添加提示文案'登录已过期，请重新登录'关联 issue: #142"
看到没？好的 commit 信息包含：
fix(auth)表示这是认证模块的修复有些团队喜欢在 commit 前加 emoji，视觉上更容易区分：
# ✨ 新功能
git commit -m ":sparkles: feat: 添加暗黑模式切换"
# 🐛 修复 bug
git commit -m ":bug: fix: 修复移动端触摸滑动卡顿"
# 📝 文档
git commit -m ":memo: docs: 更新组件库使用说明"
# ♻️ 重构
git commit -m ":recycle: refactor: 优化虚拟列表渲染性能"
# ✅ 测试
git commit -m ":white_check_mark: test: 添加支付流程 e2e 测试"
配合工具比如 gitmoji-cli，还能交互式选择 emoji，挺有意思的。
别等 push 了才发现 commit 信息写错了。可以用 Git Hooks 在提交前检查格式，后面会详细讲。
Git Hooks 是 Git 的钩子脚本，在特定事件发生时自动执行。对前端项目来说，这是保证代码质量的第一道防线。
pre-commit：提交前自动跑。最适合做代码检查。
# 项目根目录创建 .husky/pre-commit 文件（需要安装 husky）
#!/bin/sh
."$(dirname"$0")/_/husky.sh"
# 只检查暂存区的文件，提速
npx lint-staged
配合 lint-staged 配置（package.json 里）：
{
"lint-staged": {
"*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write", "git add"],
"*.{css,scss,less}": ["stylelint --fix", "git add"]
}
}
这样每次提交前，ESLint 会自动检查你改过的文件，有错误就拦住不让提交。别嫌烦，这能帮你拦住 80% 的低级错误。
pre-push：推送前自动跑。适合跑测试。
# .husky/pre-push
#!/bin/sh
."$(dirname"$0")/_/husky.sh"
# 跑单元测试
npm run test:unit
# 或者只跑相关测试（更快）
npm run test:unit -- --findRelatedTests $(git diff --name-only HEAD |grep -E '\.(js|jsx|ts|tsx)$')
测试挂了？push 失败。强制你修好了再推，避免把坏代码带到远程。
post-merge：合并后自动跑。适合安装依赖。
# .husky/post-merge
#!/bin/sh
."$(dirname"$0")/_/husky.sh"
# 检查 package.json 是否有变化，有就自动 npm install
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
if echo "$changed_files" | grep --quiet "^package\.json$"; then
echo "📦 package.json changed, running npm install..."
npm install
fi
队友升级了依赖，你 pull 代码后自动就装好了，不用手动 npm install，贴心吧？
commit-msg：检查提交信息格式。
# .husky/commit-msg
#!/bin/sh
."$(dirname"$0")/_/husky.sh"
# 用 commitlint 检查格式
npx --no-install commitlint --edit "$1"
配合 commitlint.config.js：
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};
提交信息不规范？直接打回重写。团队规范就是这么强制落地的。
现在都用 husky v7+ 版本，配置更简单：
# 安装
npm install husky lint-staged @commitlint/config-conventional @commitlint/cli --save-dev
# 初始化 husky
npx husky install
# 添加钩子
npx husky add .husky/pre-commit "npx lint-staged"
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
把这些配置提交到仓库，整个团队都能享受自动化检查，代码质量稳稳的。
.gitignore 文件是前端项目的隐私清单，告诉 Git 哪些文件别跟踪。但不同项目该忽略的东西不一样，咱得分类说清楚。
# 依赖目录（这个必须第一个写！）
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
# 构建输出
dist/
build/
out/
.next/
.nuxt/
.vuepress/dist
# 环境变量（含敏感信息）
.env
.env.local
.env.*.local
# 编辑器配置
.idea/
.vscode/*
!.vscode/extensions.json
!.vscode/settings.json
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?
# OS 生成的文件
.DS_Store
Thumbs.db
# 测试覆盖率报告
coverage/
.nyc_output/
# 日志文件
logs/
*.log
# 缓存
.cache/
.temp/
*.tsbuildinfo
.eslintcache
.stylelintcache
# React 特有
/build
# 本地环境文件（React 会自动读取.env.local）
.env.local
.env.development.local
.env.test.local
.env.production.local
# service worker
/src/serviceWorker.js.map
# Vue CLI
/dist
# 本地环境
.env.local
.env.*.local
# Vuepress
.vuepress/dist
# Vite
*.local
# 上传的文件目录（如果存在）
uploads/
public/uploads/
# 数据库文件（如果是 sqlite）
*.sqlite
*.sqlite3
# 运行时数据
pids/
*.pid
*.seed
*.pid.lock
# 生成的证书
*.pem
*.cert
*.key
如果你发现 node_modules 已经提交到仓库了，光加.gitignore 没用，得把已经跟踪的移除：
# 停止跟踪，但保留本地文件
git rm -r --cached node_modules
# 提交这个改动
git commit -m "chore: 移除误跟踪的 node_modules"
# push 到远程
git push origin main
然后 .gitignore 才会真正生效。
团队协作是 Git 的主战场，也是矛盾高发区。记住这几条，能帮你少吵架、少背锅。
main、develop 这种大家共用的分支，必须通过 PR 合并，别直接 push。这是为了防止：
# 错误示范
git checkout main
git add .
git commit -m "紧急修复"
git push origin main
# 千万别这样！
# 正确示范
git checkout -b hotfix/critical-bug
git add .
git commit -m "fix: 修复支付回调验证失败"
git push origin hotfix/critical-bug
# 然后去 GitHub 提 PR，找个人 review，再合并
提 PR 不是点一下按钮就完事了。好的 PR 描述应该包含：
## 改动内容
- 添加了用户注册时的手机号验证码功能
- 封装了通用验证码组件，支持倒计时和重发
## 为什么改动
需求文档：https://wiki.company.com/requirements/reg-with-phone
原邮箱注册转化率低，产品希望增加手机号注册提升转化
## 怎么测试
1. 进入注册页面，选择手机号注册
2. 输入手机号，点击获取验证码
3. 检查是否能正常收到短信（测试环境用模拟验证码 123456）
4. 输入错误验证码应提示"验证码错误"
5. 等待 60 秒后应能重新获取
## 截图
（这里贴 UI 效果图）
## 关联 issue
Fixes #234
队友一看就明白，review 效率也高。别写"如题"、"改了 bug"这种敷衍的。
git push --force 是核武器，只在 feature 分支上对自己用，绝对别对 main、develop 这种公共分支用。你会覆盖别人的提交，导致队友代码丢失。
如果非要用 force push（比如整理 commit 历史），用 --force-with-lease，它会检查远程是否有新提交，有的话会拒绝，防止误伤：
# 相对安全的强制推送
git push --force-with-lease origin feature/my-branch
你的 feature 分支开了三天，期间 main 分支已经合并了五个 PR。这时候你直接合进去，冲突概率很大。
养成习惯，每天开始工作前先同步：
git checkout main
git pull origin main
git checkout feature/your-branch
git rebase main
# 或者 git merge main，看团队习惯
# 解决可能的冲突后，继续开发
用 rebase 的好处是 commit 历史更线性，看着清爽；用 merge 会保留分支结构，但历史图会比较乱。团队统一一种方式就行。
review 别人的代码，别只会挑刺。好的 review 应该：
== 会有类型转换风险，建议用 ==="）被 review 的时候，别玻璃心。代码被指出问题，不代表你人不行，反而是防止你背锅。感谢每一个认真 review 你的队友。
人非圣贤，孰能无过。关键是错了之后怎么抢救。Git 提供了强大的"时光倒流"能力，但得知道怎么用。
你改了一堆文件，突然发现思路错了，想全部回退到上次提交的状态：
# 查看当前修改（确认一下）
git status
# 危险！这会丢弃所有未提交的修改，慎用
git checkout -- .
# 或者只恢复某个文件
git checkout -- src/components/WrongFile.jsx
# 新版 Git 推荐用 restore，语义更清晰
git restore .
git restore src/components/WrongFile.jsx
刚提交完，发现有个 console.log 忘了删：
# 修改文件，删掉 console.log
git add src/components/FixedFile.jsx
# --amend 修改最后一次提交，不生成新 commit
git commit --amend -m "feat: 添加用户详情页"
# 如果只是想修改文件，不想改 commit 信息
git commit --amend --no-edit
注意：如果已经 push 到远程了，amend 后需要 force push，只在个人分支上这么干。
你发现某个 commit 引入了 bug，但里面的代码还想留着改改再用：
# 查看 log，找到要撤销的 commit hash
git log --oneline -10
# 假设要撤销 abc1234 这次提交
git revert abc1234 --no-commit
# 这会生成新的修改，反向应用 abc1234 的改动
# 你可以修改这些改动，然后重新提交
git add .
git commit -m "revert: 撤销用户搜索功能的错误实现，待重构"
revert 是安全的撤销，会生成新 commit，不会改写历史。
你想放弃最近三次提交，直接回到某个稳定版本：
# 查看 log
git log --oneline
# 软回退：保留修改到暂存区，你可以重新提交
git reset --soft HEAD~3
# 混合回退：保留修改到工作区，你需要重新 add
git reset --mixed HEAD~3
# 硬回退：彻底丢弃这三次提交的修改，危险！
git reset --hard abc1234
--hard 是核武器，执行前建议先 git stash 或者备份分支。
这是最牛的功能，Git 会记录你所有的操作历史，即使 reset --hard 了也能找回来：
# 查看操作历史（像时光机一样）
git reflog
# 输出类似：
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: feat: 添加支付功能
# 9ab9012 HEAD@{2}: commit: fix: 修复购物车计算错误
# 发现 def5678 是你要找回的 commit
git checkout -b recovery-branch def5678
# 或者直接用 reset 恢复
git reset --hard def5678
reflog 默认保留 30 天，所以只要发现得及时，基本都能救回来。
队友在某个分支上写了个超棒的工具函数，你想"偷"到自己分支，但不想合并整个分支：
# 查看那个 commit 的 hash，比如是 f8d3a21
git cherry-pick f8d3a21
# 如果有冲突，解决后
git add .
git cherry-pick --continue
# 如果想放弃这次 cherry-pick
git cherry-pick --abort
这就像是精准复制某次提交，很实用的技巧。
Git 默认对代码差异的展示比较通用，但针对 JS 项目，我们可以让它更智能。
默认的 diff 对 JSX 支持不好，可以配置更友好的展示：
# 配置 Git 使用更智能的 diff 算法
git config --global diff.algorithm histogram
# 对特定文件类型使用特殊 diff
echo "*.jsx diff=jsx">> .gitattributes
echo "*.tsx diff=tsx">> .gitattributes
或者用第三方 diff 工具，比如 delta，支持语法高亮：
# 安装 delta（用 brew 或 cargo）
brew install git-delta
# 配置 Git 使用 delta
git config --global core.pager delta
git config --global interactive.diffFilter 'delta --color-only'
git config --global delta.syntax-theme Dracula
git config --global delta.line-numbers true
这样 git diff 看 JSX 代码时，有语法高亮，变更行也标得清楚，review 体验大幅提升。
看到一坨烂代码，想知道谁写的？别在群里吼，用 git blame：
# 查看某文件的每一行是谁写的
git blame src/utils/messyCode.js
# 只看某几行（比如 100-120 行）
git blame -L 100,120 src/utils/messyCode.js
# 忽略空白字符的改动（格式化导致的无关变更）
git blame -w src/utils/messyCode.js
输出会显示每行最后的修改者、时间和 commit。但注意，blame 是查最后修改的人，不是原始作者。如果某人只是格式化了下代码，会显示他的名字。配合 -w 参数可以一定程度上避免这个问题。
想知道某个函数是怎么一步步变成现在这样的：
# 查看某文件的变更历史，带详细 diff
git log -p src/components/Evolution.jsx
# 只查看涉及某函数的提交（用-S 搜索）
git log -S "function oldFunctionName" src/components/Evolution.jsx
# 图形化查看（如果装了 tig 等工具）
tig src/components/Evolution.jsx
写到一半，突然要切分支修紧急 bug？别急着 commit 半成品，用 stash：
# 把当前修改存起来，工作区变干净
git stash push -m "用户头像上传功能写到一半"
# 修完 bug 回来，恢复
git stash pop
# 如果 stash 多了，查看列表
git stash list
# 恢复指定的 stash
git stash apply stash@{1}
如果你发现连续三个 commit 都忘了加 issue 编号，或者作者信息写错了，可以用交互式 rebase：
# 修改最近 4 次提交
git rebase -i HEAD~4
# 会打开编辑器，显示：
# pick abc1234 feat: 添加登录页
# pick def5678 fix: 修复样式
# pick 9ab9012 feat: 添加注册页
# pick 1cd2345 fix: 修复验证
# 把需要修改的 commit 前面的 pick 改成 edit 或 reword
# edit：停下来让你修改
# reword：只改 commit 信息
# 保存退出后，按提示操作
# 改完用 git rebase --continue 继续
注意：已经 push 到远程的 commit，别用 rebase 修改，会改写历史导致队友混乱。只用于本地整理 commit。
写到这儿，我突然想起刚学 Git 那会儿，觉得这些命令又臭又长，哪有 Ctrl+Z 来得痛快。直到被现实毒打了几轮——丢过代码、背过锅、凌晨三点还在解冲突——才真正理解 Git 的价值。
Git 这玩意儿，说白了就是个保险 + 记账 + 协作的工具。它不能保证你代码写得牛，但能保证你写得再烂也有退路，保证你和队友不会互相踩脚，保证项目历史清清楚楚谁也别想赖账。
别等项目炸了才想起学 Git，那时候往往已经晚了。现在就试试那些你觉得"太麻烦"的命令：建个分支玩一玩，故意制造个冲突解一解，用 reflog 找回被 reset 的 commit。玩熟了，下次团建的时候，说不定你就是那个帮全组 recover 代码的英雄，奶茶随便点的那种。
还有啊，Git 虽然强大，但也不是万能的。它管的是代码版本，管不了你代码里的逻辑错误，也管不住你把 API 密钥写死在代码里的手。好代码还是得靠脑子写，Git 只是帮你保管好这些脑子里的产物。
行了，今天就唠到这儿。去试试吧，记得把 .gitignore 先写好，别又给我把 node_modules 传上来了，看着头大。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online