电脑操作小技巧

发表于 更新于 分类于 阅读次数： 本文字数： 2.8k 阅读时长 ≈ 7 分钟
这篇文章会阐述一些操作电脑的小技巧，可以帮助你在一定程度上提升操作效率、优化电脑性能。

解决文件夹进程占用与权限问题

针对Windows 11家庭中文版中因进程占用或权限不足导致的文件夹删除难题，以下是结合系统原生命令的解决方案

一、终止占用文件的进程（可选）

如果文件夹被其他程序占用（如后台进程或病毒），需先终止相关进程：

  1. 通过任务管理器手动结束进程（常规操作）

鼠标右键单击任务栏，点击任务管理器，进而在“进程”栏中搜索并结束任务

  1. 命令行终止进程（需管理员权限）：

    按win+R，输入cmd，进而按Ctrl+Shift+Enter以管理员权限打开

    1
    taskkill /f /im "进程名.exe"

    示例：若资源管理器占用，可重启资源管理器

    1
    taskkill /f /im explorer.exe && start explorer.exe

二、获取文件夹所有权并赋予完全控制权限

通过CMD管理员命令强制获取权限：

  1. 获取所有权：

    1
    takeown /f "文件夹路径" /r /d y
    • /r：递归操作子文件
    • /d y：静默确认（无需交互）

  2. 赋予管理员完全控制权限：

    1
    icacls "文件夹路径" /grant Administrators:F /t

    • /grant Administrators:F：授予管理员完全控制权

    • /t：递归应用到子项

三、强制删除文件夹

CMD命令

1
rd /s /q "文件夹路径"

参数解析：

  • /s：删除文件夹及子内容
  • /q：静默模式（无确认提示）

Powershell指令

1
2
3
takeown /f "文件夹路径" /r /d y  
icacls "文件夹路径" /grant Administrators:F /t  
Remove-Item -Path "文件夹路径" -Force -Recurse

扩展：解决深层权限问题的进阶命令

若上述步骤仍失败，可尝试重置权限继承（修复权限混乱）

1
icacls "文件夹路径" /reset /t /c /l
  • /reset：恢复默认权限
  • /t：递归操作子项

Github大文件警告

在Github中，如果我们使用Git来记录，如果我们不慎提交了大文件，即使当前提交移除了大文件，历史记录中可能仍有残留。

你可能误以为强制推送能解决问题，但实际上，如果历史提交中的大文件未被处理，GitHub仍然会检测到并发出警告。需要确保所有历史中的大文件都被迁移或删除，而不仅仅是当前提交。

在这里，我们以.flac音频文件为例，向大家讲解如何解决Github大文件警告问题

核心原因分析

  1. 未正确使用 Git LFS 追踪大文件 若历史提交中仍存在大文件记录，GitHub 仍能检测到旧版本中的大文件残留

  2. Git LFS 配置不完整 如果未执行完整的 LFS 初始化、文件追踪和 .gitattributes 提交，系统仍会以普通 Git 方式处理大文件

  3. 缓存或历史记录未清理 本地 .git 目录可能保留旧对象，或 GitHub 服务端缓存未刷新，导致历史文件仍被检测

分步解决方案

  1. 下载 Git LFS 安装包
  • 访问Git LFS 官网，点击 “Download” 获取 Windows 版 .exe 安装程序
  1. 运行安装程序
  • 双击下载的 git-lfs-windows-amd64-v3.4.0.exe 文件，按默认路径安装
  1. 验证 LFS 安装

  • 在 Git Bash 中输入：

    1
    git lfs version

    若显示版本号（如 git-lfs/3.4.0）则安装成功

配置Git LFS管理大文件

  1. 初始化 LFS 支持

  • 在 Git Bash 中执行全局初始化：

    1
    git lfs install

    此命令会在所有仓库中启用 LFS 支持

  1. 指定需追踪的大文件类型

    进入你的项目目录（例如 cd ~/myblog），执行：

    1
    2
    git lfs track "*.flac"   # 追踪所有 .flac 音频文件
    git lfs track "*.zip"   # 追踪所有的.zip 压缩包文件

    生成的 .gitattributes 文件将记录追踪规则

  2. 提交配置文件

    1
    2
    git add .gitattributes
    git commit -m "启用 Git LFS 追踪大文件"

迁移历史大文件到 LFS（解决现有仓库问题）

  1. 清理历史大文件

    1
    git lfs migrate import --include="*.flac" --everything

    此命令会重写提交历史，将匹配文件迁移到 LFS

  2. 强制推送更新

    1
    git push --force

    覆盖远程仓库历史记录

验证与维护

  1. 检查已追踪文件

    1
    git lfs ls-files   # 显示通过 LFS 管理的文件列表

  2. 更新 LFS 缓存

    1
    git lfs prune      # 清理本地不再引用的 LFS 文件

通过以上步骤，你的Github大文件警告问题可能得到彻底解决。如不能彻底解决，那大概就是本地的git嵌套仓库问题，解决该问题并不在笔者的能力范围之内。笔者的方式是重置了自己的网站（你没听错，是把一切重新推倒重来！）

如果有读者拥有能够解决该问题的方法，欢迎交流分享，我将不胜感激！

SSH连接阻断解决

确定问题根源

连接Github时，显示 Connection reset by 20.205.243.166 port 22 错误，通常是因为网络环境（如防火墙、代理、ISP 限制等）阻断了 SSH（端口 22）的连接。

此错误表明尝试通过 SSH 端口 22 连接到 GitHub 时，连接被远程服务器（如防火墙或网络代理）强制关闭。可能的原因：

  • 网络防火墙/代理：公司、学校网络或本地防火墙阻止了 SSH 流量。
  • ISP 限制：某些地区或网络运营商屏蔽了 SSH 端口（如国内部分网络）。
  • GitHub 服务异常：极少数情况下可能是 GitHub 的 SSH 服务临时故障。

解决方案

如果仍希望使用 SSH，但端口 22 被阻，可改用 GitHub 提供的 SSH over HTTPS 端口 443：

  1. 修改SSH配置：

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

  2. 添加以下内容：

    1
    2
    3
    4
    5
    Host github.com
      Hostname ssh.github.com
      Port 443
      User git
      IdentityFile ~/.ssh/id_rsa  # 替换为你的私钥路径

    如何确定你的私钥路径？

    无论你生成的是 ed25519 还是 rsa 类型密钥，私钥路径遵循以下规则：

    1
    2
    3
    4
    ~/.ssh/id_{算法类型}  
    例如：
    ~/.ssh/id_ed25519     # ed25519 私钥（推荐）
    ~/.ssh/id_rsa         # RSA 私钥（传统算法）

    操作步骤：

    1. 打开终端：在 Hexo 项目文件夹右键打开 Git Bash

    2. 进入SSH目录并查看文件

      1
      2
      3
      4
      5
      # 进入 .ssh 目录
      cd ~/.ssh

      # 查看所有文件（显示隐藏文件）
      ls -al

    3. 识别你的私钥文件

      • 私钥特征：
        • 文件名以 id_ 开头，没有 .pub 后缀
        • 常见名称：id_ed25519（推荐）或 id_rsa（传统）
      • 公钥特征：
        • 文件名以 .pub 结尾
        • 如 id_ed25519.pub

    4. 保存并退出

      • 保存文件：快捷键Ctrl+O
      • 屏幕底部会显示 File Name to Write: ~/.ssh/config，直接按 回车（Enter） 确认保存。
      • 退出编辑器：快捷键Ctrl+X

    5. 验证是否保存成功

      • 查看文件内容

        1
        cat ~/.ssh/config
        • 如果看到你添加的配置（如 Host github.com 等），说明保存成功。

  3. 测试连接：

    1
    ssh -T git@github.com
    • 成功响应：Hi username! You've successfully authenticated...

回顾分析

无法通过 SSH（端口 22）连接 GitHub，但换成 SSH over HTTPS（端口 443） 后成功了，原因通常与 网络环境对端口 22 的限制 有关

端口 22 被网络阻断
  • SSH 默认端口 22 是许多网络环境（如公司、学校、公共 WiFi）的常见封锁目标，原因包括：
    • 安全策略：防止内部人员或外部攻击者通过 SSH 端口发起攻击。
    • ISP 限制：某些地区的网络运营商（尤其是国内）会屏蔽端口 22，以减少滥用风险。
    • 防火墙规则：本地防火墙或路由器可能主动拦截端口 22 的流量。
  • 当尝试 ssh -T git@github.com 时，连接被远端 IP 20.205.243.166（GitHub 服务器）的端口 22 重置（Connection reset），表明流量在到达 GitHub 前已被阻断。
端口 443 的“特权”
  • 端口 443 是 HTTPS 协议的标准端口，几乎不会被封锁，因为：
    • 合法用途广泛：所有 HTTPS 网站（如银行、电商）都依赖此端口。
    • 加密流量：网络设备难以区分 HTTPS 流量中是否混用了其他协议（如 SSH over 443）。
  • GitHub 的兼容性设计： GitHub 专门在端口 443 上提供 SSH 服务（通过域名 ssh.github.com），让用户能在端口 22 被封锁时，仍能通过 443 端口使用 SSH。
为什么切换到端口 443 后成功了？
  • 绕过端口限制： 当你修改 ~/.ssh/config，强制 SSH 客户端通过端口 443 连接 GitHub 时，流量伪装成 HTTPS 流量，顺利通过防火墙或 ISP 的过滤规则。
其他可能原因
  • 本地代理/VPN 干扰：某些代理工具会干扰 SSH 流量，但改用 443 后流量更“合法”。
  • GitHub 服务器负载：极少数情况下，GitHub 的 SSH 服务端可能临时拒绝连接（但概率极低）。