影响极小指改动在多数场景下不改变行为或性能，但边界case中可能暴露问题；如Math.round(0.5)因规范与实现差异曾返回0，现统一为1；git amend后需--force-with-lease推送；list.sort()原地排序内存低，sorted()新建列表开销大。
影响极小，通常意味着你正在处理的改动、配置或函数调用在绝大多数实际场景中不会改变行为、性能或结果。但这不等于“可以忽略”——它往往藏在边界 case 里。
为什么 Math.round(0.5) 在某些 JS 环境返回 0？
这不是 bug，而是规范差异：Math.round() 在 ECMAScript 中定义为“四舍五入到最近的整数，.5 向正无穷舍入”，但早期 V8（Chrome 40 之前）和部分旧版 Safari 实现为“向偶数舍入”。
- 现代环境（Chrome ≥ 41、Firefox、Node.js ≥ 12）统一遵循 ES 规范：
Math.round(0.5) === 1 - 若需跨环境一致，改用
Math.floor(x + 0.5)（仅适用于非负数）或Math.trunc(x + 0.5) - 注意：
Math.round(-0.5)在所有合规实现中都返回0，不是-1—— 这是很多人误以为“不一致”的真正来源
git commit --amend 修改最近一次提交后，push 失败怎么办？
因为 --amend 生成了新 commit hash，本地 HEAD 和远程分支已分叉，直 push 会被拒绝。
- 确认你没推送给他人协作的分支（如 main / develop），否则强制推送会破坏他人工作
- 若仅自己使用，执行
git push --force-with-lease origin main（比--force更安全） -
--force-with-lease会检查远程引用是否被他人更新，避免覆盖他人新提交 - CI/CD 流水线可能缓存旧 commit ID，修改后需手动触发重跑
Python 中 list.sort() 和 sorted() 的内存开销差异
两者算法复杂度都是 O(n log n)，但内存表现不同：
-
list.sort()原地排序，额外内存 ≈ O(log n)（仅递归栈） -
sorted()总是新建 list，额外内存 ≈ O(n) - 对大列表（如百万级字符串），
sorted()可能触发频繁 GC 或内存不足，而.sort()更稳 - 注意：
.sort()返回None，写成a = a.sort()会让a变成None—— 这是最常踩的坑
“影响极小”的判断，往往依赖于你的数据规模、运行时环境版本、并发模型和协作流程。它不像语法错误那样立刻报红，但会在某个周五下午三点，当订单号突然少了一位、日志时间戳乱序、或者 CI 构建卡在 97% 时，才真正浮现。
