踩坑

> Last Format Time：7/14/2026 20:56:57

Git

develop分支

我最开始开发的时候直接在main分支上切出来的，然后就去写代码了，导致我后面的cherry-pick的时候有666个冲突，而且很多的模块在develop分支已经被删除了，导致很多逻辑要重写。。。

被合并的pr依旧有问题的处理

首先需要明确一个关键点：PR 被合并后，你的代码就已经正式成为项目主分支（如 main 或 develop）的一部分了。因此，你不需要也不应该再切回原来那个已经被合并的分支去修改，否则很容易把旧的历史改动带入新任务中。

针对评论中提出的问题，正确的处理方式是基于最新的主分支创建一个全新的功能分支来进行修复。具体操作步骤如下：

首先，切回主分支并拉取包含你刚刚合并代码的最新版本：

git checkout main
git pull origin main

基于最新的 main 分支，创建一个专门用于处理这些评论反馈的新分支。建议命名包含 fix 或 refactor 等前缀以区分：

git checkout -b fix/address-pr-comments

在新分支上针对评论中的问题进行修改，然后提交并推送到远程仓库：

# 修改代码后...
git add .
git commit -m "fix: address review feedback regarding login logic"
git push origin fix/address-pr-comments

推送完成后，在代码托管平台（如 GitHub/GitLab）上基于这个新分支再次发起一个新的 Pull Request，并在描述中说明这是为了解决上一个 PR 的遗留问题（也可以关联之前的 Issue）。

💡 补充说明：如果 PR 尚未合并 如果你的 PR 还在审查阶段（未合并），且维护者留下了修改意见，那么处理方式完全不同：

• 不要新建分支，也不需要关闭当前的 PR。
• 直接在你原来的分支上继续修改代码。
• 修改完成后，使用 git push origin 你的分支名 推送更新，新的提交会自动追加到现有的 PR 中，审查者就能看到最新的改动。

组件

路由与组件没有分开写

在前端开发中，将组件（Component）与路由（Router）分开编写（即“路由解耦”），是现代前端架构中非常重要的一项最佳实践。这种设计模式的核心在于职责分离。

将组件置于pages中，路由置于ruotes中： 

环境

看不清的类型提示

可以按住Ctrl来点击： 

也可以安装插件去展示：