Tech-Paul

work hard, play hard

Posted on

要在本地同时管理 GitHub 和 GitLab 的 SSH 连接，核心思路是为不同平台生成独立的密钥对，并通过 SSH 配置文件 (config) 自动匹配。这样在拉取或推送代码时，系统会自动选择对应的密钥，互不干扰。

以下是详细的配置步骤（以 macOS/Linux 为例，Windows 用户请在 Git Bash 中操作）：

第一步：生成两对独立的 SSH 密钥

建议使用 ed25519 算法（更安全）或 rsa。生成时务必使用 -f 参数指定不同的文件名，避免覆盖。

打开终端，执行以下命令：

1
2
3
4
5
# 为 GitHub 生成密钥
ssh-keygen -t ed25519 -C "your-email@github.com" -f ~/.ssh/id_ed25519_github

# 为 GitLab 生成密钥
ssh-keygen -t ed25519 -C "your-email@gitlab.com" -f ~/.ssh/id_ed25519_gitlab
  • 说明：按回车后，如果提示设置密码（passphrase），可以设置（推荐）或直接留空。完成后会在 ~/.ssh/ 目录下生成 4 个文件：id_ed25519_github（私钥）、id_ed25519_github.pub（公钥）、id_ed25519_gitlab、id_ed25519_gitlab.pub。

第二步：将公钥分别添加到远程平台

  1. 复制公钥内容：
    1
    2
    3
    4
    # 查看并复制 GitHub 公钥
    cat ~/.ssh/id_ed25519_github.pub
    # 查看并复制 GitLab 公钥
    cat ~/.ssh/id_ed25519_gitlab.pub
  2. 添加公钥：
    • GitHub：登录 GitHub -> Settings -> SSH and GPG keys -> New SSH key -> 粘贴 id_ed25519_github.pub 的内容。
    • GitLab：登录 GitLab -> 点击头像 -> Preferences -> SSH Keys -> 粘贴 id_ed25519_gitlab.pub 的内容。

第三步：配置 SSH Config 文件（关键）

在 ~/.ssh/ 目录下创建或编辑 config 文件，告诉 SSH 客户端“访问哪个域名用哪把钥匙”。

1
2
# 编辑配置文件
vim ~/.ssh/config

文件内容示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
# GitHub 配置
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

# GitLab 配置
Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitlab
    IdentitiesOnly yes
  • 参数解释：
    • Host：匹配的域名（即你 clone 地址中的 git@ 后面的部分）。
    • IdentityFile：指定该域名使用的私钥路径。
    • IdentitiesOnly yes：强制只使用配置文件中指定的密钥，不尝试默认密钥，避免混淆。

第四步：测试连接与权限

配置完成后，测试连接是否成功：

1
2
3
4
5
6
7
# 测试 GitHub
ssh -T git@github.com
# 成功会显示：Hi your-username! You've successfully authenticated...

# 测试 GitLab
ssh -T git@gitlab.com
# 成功会显示：Welcome to GitLab, @your-username!

如果出现 Permission denied (publickey) 错误，请检查第 2 步公钥是否添加正确，或尝试重启 SSH 代理：eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519_github。

第五步：项目级 Git 用户配置（提交记录隔离）

SSH 只负责“通道”认证，提交代码时的作者信息（Commit Author）由 Git 配置决定。为了避免用公司邮箱提交到个人项目，建议在项目目录内单独设置：

1
2
3
4
5
6
# 进入项目根目录
cd /path/to/your-project

# 设置该项目的专属用户信息
git config user.name "Your Name"
git config user.email "your-email@domain.com"
  • 全局配置：如果你大部分项目都用同一个身份（如 GitHub），可以设置全局默认值：git config --global user.name "Global Name"，然后在个别项目（如 GitLab 项目）中执行上述局部配置进行覆盖。

常见问题排查

  • 克隆现有项目：如果项目之前是 HTTPS 方式克隆的，需要修改远程地址为 SSH：
    1
    git remote set-url origin git@github.com:username/repo.git
  • 权限错误：运行 ssh -vT git@github.com 查看详细日志，通常能发现是哪个环节的密钥没被正确加载。
  • Windows 路径：Windows 用户密钥通常存放在 C:\Users\YourUserName\.ssh\，配置文件路径同理。

按照以上步骤操作，你的本地环境就能清晰地区分 GitHub 和 GitLab 的 SSH 身份了。

首次pull 平台项目错误提示

1
2
3
4
5
clone git@gitee.com:muzhi7/thinklogparser-web.git thinklogparse
Cloning into 'thinklogparse'...
The authenticity of host 'gitee.com (180.76.199.13)' can't be established.
ED25519 key fingerprint is SHA256:+ULzij2u99B9eWYFTw1Q4ErYG/aepHLbu96PAUCoV88.
This key is not known by any other names.

核对一下 known_hosts 是否已有 gitee.com 记录，再结合你的 ~/.ssh/config 解释原因，这样能明确为什么首次连接会出现那条提示。

这是正常现象，和你的 SSH key 配置本身不冲突。

原因是：

  1. ~/.ssh/config 只负责告诉 SSH “连到哪个域名时用哪把私钥”，不负责“信任这个主机是谁”。
  2. 你第一次用 SSH 连接 gitee.com 时，本机的 ~/.ssh/known_hosts 里还没有 gitee.com 的主机公钥记录。
  3. 所以 OpenSSH 会提示：
    The authenticity of host … can’t be established.
    让你确认一次，防止中间人攻击。
  4. 你输入 yes 后，主机公钥被写入 ~/.ssh/known_hosts，后续再连同一个主机通常就不会再提示了。

你这次日志也印证了这一点：

  • 当时提示 unknown host
  • 你确认 yes
  • 随后显示 Permanently added gitee.com
  • 现在我检查到 known_hosts 已有 gitee.com 记录

补充：
如果未来再次出现同类提示，常见是以下情况之一：

  1. 换了新机器或清空了 known_hosts
  2. 用了新的主机名/别名连接（例如 IP、不同域名）
  3. 远端平台更换了主机密钥（这时要谨慎核对官方指纹后再接受）

Posted on Edited on

Chrome DevTools 的 Performance 面板（旧称 Timeline）是用于记录和分析网页运行时性能的核心工具。它通过火焰图、时间轴和指标数据，帮助你定位页面卡顿、加载缓慢等性能瓶颈。

以下是详细的使用步骤和核心功能解析：

  1. 准备工作：模拟真实环境

为了获得更贴近用户真实体验的数据，建议在测试前进行环境配置：
• 开启无痕模式：避免浏览器扩展插件干扰测试结果。

• 开启 CPU 节流：在面板右上角的设置中，将 CPU 设置为 4x slowdown 或 6x slowdown，模拟移动设备的低性能 CPU。

• 开启网络节流：在设置中，将 Network 设置为 Slow 3G 或 Fast 3G，模拟较差的网络环境。

  1. 核心操作：记录性能数据

根据你的测试目标，选择不同的记录方式：

操作 适用场景 步骤

页面加载分析 分析首次打开页面的速度（LCP、FCP 等） 点击面板左上角的 圆形刷新按钮（Reload page），DevTools 会自动记录页面加载过程并生成报告。

运行时分析 分析用户交互（点击、滚动）或动画的流畅度 点击面板左上角的 黑色圆形按钮（Record），在页面上进行交互操作，然后点击 Stop 按钮结束记录。

  1. 分析报告：解读关键数据

记录完成后，面板会显示详细的性能报告。重点关注以下三个区域：

A. 概览区域（Overview）

位于报告顶部，显示关键指标的时间轴：
• FPS（绿色）：帧率。红色长条表示帧率过低，页面出现卡顿。

• CPU（彩色）：CPU 使用率。颜色对应底部的 Summary 面板，显示时间花在了脚本、渲染还是绘制上。

• NET（彩色）：网络请求瀑布流，显示资源加载顺序和耗时。

B. 火焰图（Flame Chart / Main）

这是定位性能瓶颈最核心的工具：
• X 轴：时间。横条越长，耗时越长。

• Y 轴：调用栈。上层函数调用下层函数。

• 操作技巧：

◦   放大：使用鼠标滚轮或拖动时间轴选择器，聚焦到卡顿区域。

◦   查看详情：点击火焰图中的某个任务，底部的 Summary 面板会显示该任务的耗时和具体代码位置（点击链接可直接跳转到 Sources 面板）。

C. 摘要面板（Summary）

位于底部，显示选中时间段的统计信息：
• Scripting：JavaScript 执行时间。

• Rendering：样式计算和布局（Layout）时间。

• Painting：绘制时间。

• System：浏览器系统时间。

  1. 高级功能

• 实时 Core Web Vitals：面板顶部会实时显示 LCP（最大内容绘制）、CLS（累积布局偏移） 和 INP（交互到下次绘制） 的分数，帮助你快速判断页面是否符合 Google 的体验标准。

• 截图（Screenshots）：在设置中勾选 Screenshots，记录过程中会截取页面快照。在概览区域左右滑动鼠标，可以像看视频一样回放页面渲染过程，直观看到页面何时变白、何时出现内容。

  1. 常见性能问题与排查

• 页面卡顿（Jank）：查看 FPS 图表是否有红色长条，然后在火焰图中找到对应的长任务（Task），优化 JavaScript 执行逻辑。

• 加载慢：查看 NET 区域，检查是否有大文件阻塞渲染，或 DNS 查询时间过长。

• 内存泄漏：勾选 Memory 选项后记录，如果 JS Heap 内存曲线持续上升而不下降，可能存在内存泄漏。

Posted on Edited on

索引额外开销内存

每个索引占据一定的存储空间，在进行插入，更新和删除操作时也需要对索引进行操作

内存限制

索引是存储在内存(RAM)中,你应该确保该索引的大小不超过内存的限制。

如果索引的大小大于内存的限制，MongoDB 会删除一些索引，这将导致性能下降。

查询限制

索引不能被以下的查询使用：

  • 正则表达式及非操作符，如 $nin, $not, 等。
  • 算术运算符，如 $mod, 等。
  • $where 子句

MongoDB 对查询的限制包括：

  • 每个查询最多返回 100,000 个文档
  • 每个查询最多返回 16 MB 的数据
  • 每个查询最多执行 10 分钟
0%