❌

普通视图

发现新文章，点击刷新页面。
今天 — 2025年5月23日掘金 前端

【滑动窗口算法实战】最小子串和最小覆盖子串问题（JS + Python 双解）

✇掘金 前端
作者 前端付豪
2025年5月23日 17:06
【滑动窗口算法实战】最小子串和最小覆盖子串问题（JS + Python 双解） 🧠 引言 你是否遇到过这些场景？ 在字符串中找出“最短连续子串”，满足某些条件 判断一个数组内是否存在“某长度内的目标和

Git大小写引发的问题：从v1到V1引发的血案

✇掘金 前端
作者 独立开阀者_FwtCoder
2025年5月23日 17:32

作者：程序员平

最近在开发过程中遇到了的一个诡异的问题：我们的项目中有一个目录原本命名为v1，已经添加并纳入了Git管理。后来由于规范调整，我们将目录名从v1改为V1，修改了代码命令空间并提交代码Action自动化部署后却发现服务器上的代码运行出现了问题——系统依然尝试访问v1目录，导致各种路径错误。最近我就在一次部署中因为这个问题踩了坑，本文记录这个问题的复现过程、根因分析以及解决，希望能帮到你。

最近在开发过程中遇到了一个诡异的问题：我们的项目中有一个目录原本命名为v1，已经添加并纳入了Git管理。后来由于规范调整，我们将目录名从v1改为V1，提交代码后却发现服务器上的代码运行出现了问题——系统依然尝试访问v1目录，导致各种路径错误。

一、背景描述

这个示例我就新建一个测试的仓库进行演示!

项目结构中原本有一个目录为 v1/（小写），已经被添加到 Git 仓库中。

图片

后来为了统一风格，我将目录名改成了 V1/（首字母大写），并正常修改代码执行提交/push

图片

一切看起来都没问题，直到部署到服务器后，服务报错找不到 V1 目录。登录服务器后发现目录仍然是 v1，并未变成大写。此时我才意识到，这不是部署的问题，而是 Git 根本没有识别到目录名的大小写变化。

其实单独修改目录, 不修改代码就会发现, 将目录名改为大写的V1之后, 其实是没有要提交的内容的

二、 为什么会出现这个问题？

1. Git 默认配置下不区分大小写

Git在默认配置下对文件名是大小写不敏感的。这意味着当你把v1改为V1时，Git可能不会将其识别为一个真正的更改，特别是如果你没有明确配置Git为大小写敏感。

这意味着：在 macOS 或 Windows 上将目录 v1 改名为 V1，文件系统会认为这不是“真正的重命名”，Git 也就不会记录这个变动。

如果你是在本地开发（Windows/macOS），然后部署到 Linux 服务器（大小写敏感），问题就暴露了。

2. Git的工作机制

  • 当你在本地重命名文件夹时：
    • 本地文件系统会反映这个更改
    • Git可能不会将此识别为重命名操作，而是认为你删除了v1并添加了V1
    • 如果Git配置为不区分大小写，它可能完全忽略这个更改

3. 文件系统的差异

不同操作系统对文件名大小写的处理方式不同：

  • Windows/macOS(默认)：文件系统通常不区分大小写
  • Linux/Unix：文件系统通常区分大小写

三、 如何解决？

方法一

使用 git mv 强制重命名(临时)

# 先改成一个临时名称（不同名）git mv v1 tempgit commit -m "Temp rename"
# 再改为最终名称git mv temp V1git commit -m "Rename v1 to V1"git push

这样就能强制 Git 识别为两个变更，从而在使仓库中都能正确更新。

图片

方法二

修改 Git 配置以区分大小写（永久）

配置Git为大小写敏感：

git config core.ignorecase false

这个配置告诉 Git 让它在本地也“强制”区分大小写。

四、 总结****

Git的大小写不敏感特性在跨平台开发中可能成为隐形杀手, 特别是在一开始就没有统一文件命名规范的时候。通过了解其工作原理并采取适当的预防措施，可以避免这类问题的发生。记住，在重命名文件或目录时，最好使用git mv命令，并确保团队中每个人都配置了正确的大小写敏感设置。

运行一个已有的 Vue 项目

✇掘金 前端
作者 Emma歌小白
2025年5月23日 17:21

运行一个已有的 Vue 项目通常包括以下几个步骤。以下以典型 Vue CLI 项目为例（也适用于 vite 项目，下面会分别说明）：

🧭 你要确认的项目结构（例如）

假设你 Vue 项目的目录是 open_site_vue：

open_site_vue/
├── package.json
├── node_modules/
├── src/
├── public/
├── vite.config.js 或 vue.config.js
└── ...

✅ 1. 安装依赖

打开终端（PowerShell、CMD 或 Git Bash），进入 Vue 项目目录：

cd open_site_vue

然后执行：

npm install

如果你用的是 pnpm 或 yarn，可以改成：

yarn    # 或 pnpm install

✅ 2. 启动开发服务器

Vue CLI 项目（vue.config.js）

npm run serve

Vite 项目（vite.config.js）

npm run dev

运行成功后会看到：

App running at:
  - Local:   http://localhost:5173/ （或 http://localhost:8080）

点击链接或复制到浏览器中即可预览。

✅ 3. Vue 编译后用于 Django 的方式（如你是前后端分离项目）

通常你会：

（1）编译 Vue 项目：

npm run build

这会生成一个 dist/ 目录（Vite）或 dist/（Vue CLI），你可以将该目录部署到 Django 的 static 路径下，或用 nginx/Apache 进行反向代理。

（2）把 dist/index.html 改成 Django 模板 或 iframe 嵌入也可以。

❗常见问题排查

问题类型 可能原因 解决方案
npm install 报错 没装 Node.js 去 nodejs.org 安装
启动后空白页 路由模式是 history 要在服务器配置 fallback 或 Django 中处理 404
编译出错 模块找不到 确保运行过 npm install，并检查 Vue 版本

新手易混淆的TS配置：paths、types、include对比

✇掘金 前端
作者 火车叼位
2025年5月23日 17:08

在TypeScript项目中，tsconfig.json的配置直接决定了代码编译、类型检查和模块解析的底层行为。尽管官方文档对各项参数有基础说明，但实践中开发者常对paths、types、include三个配置产生混淆。本文将通过原理剖析、对比表格与真实案例，彻底解析它们的差异与配合技巧。

一、三大配置核心定位速览

1.1 配置对比表

配置项 作用域 典型应用场景 关联配置
paths 模块解析路径映射 简化长导入路径、实现多环境路径切换 baseUrl
types 全局类型声明管控 避免类型污染、加速类型检查 typeRoots
include 编译范围控制 排除测试文件、限定源码目录 exclude/files

二、配置项深度解析

2.1 paths：模块路径的导航仪

核心作用

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@utils/*": ["src/core/utils/*"],
      "type/*": ["types/*"] 
    }
  }
}
  • 路径别名：将冗长的import '../../core/utils/logger'简化为@utils/logger
  • 环境适配：通过不同配置实现开发/生产环境的路径切换
  • 多包管理：在monorepo中跨package引用时消除路径混乱

注意事项

  • 必须与baseUrl配合使用
  • 仅影响TypeScript类型检查，需配合Webpack/Vite等构建工具实现运行时解析

2.2 types：全局类型的守门员

典型配置

{
  "compilerOptions": {
    "types": ["node", "jest"],
    // typeRoots默认值：["node_modules/@types"]
  }
}
  • 类型隔离：仅允许声明的类型包参与全局类型推导
  • 性能优化：减少不必要的类型扫描（如禁用未使用的Lodash类型）
  • 冲突解决：当多个@types包存在命名冲突时选择性加载

常见误区

  • ❌ 误认为types用于声明项目自定义类型（实际应使用include包含声明文件）
  • ❌ 在已有typeRoots配置时重复声明@types路径

2.3 include：编译范围的边界线

标准用法

{
  "include": [
    "src/**/*.ts",
    "types/**/*.d.ts",
    "configs/*.ts"
  ],
  "exclude": ["**/__tests__"]
}
  • 精准控制：仅编译业务代码，排除测试文件/脚本工具
  • 声明文件管理：明确包含自定义类型声明目录
  • 增量编译：通过范围限定提升tsc --watch性能

高级技巧

  • 使用!否定符实现复杂过滤：["src/**/*", "!src/experimental"]
  • 与files配置搭配使用，实现"白名单+黑名单"双保险

三、配置间的协同效应

3.1 典型项目结构配置

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"],
      "types/*": ["typings/*"]
    },
    "types": ["vite/client"],
    "typeRoots": ["./typings", "./node_modules/@types"]
  },
  "include": ["src", "typings", "vite.config.ts"]
}
  • 路径映射：@/components/Button → src/components/Button
  • 类型管理：仅加载vite客户端类型，防止React/Vue类型冲突
  • 编译范围：包含业务代码+自定义类型声明

3.2 常见问题排查指南

问题1：类型声明未生效

  • ✅ 检查include是否包含声明文件目录
  • ✅ 确认types未过滤掉必要类型包
  • ✅ 确保声明文件格式为.d.ts且无语法错误

问题2：模块路径解析失败

  • ✅ 验证baseUrl是否指向正确根目录
  • ✅ 在构建工具中同步配置路径别名（如vite.config.ts）
  • ✅ 使用tsc --traceResolution查看详细解析过程

四、最佳实践推荐

  1. 路径管理三板斧

    • 基础路径：baseUrl: "."
    • 别名映射：paths: { "@/*": ["src/*"] }
    • 构建工具联动：在Webpack/Vite中配置相同别名

  2. 类型安全双保险

    {
  "types": ["vite/client"], // 显式声明环境类型
  "include": ["src", "typings"] // 包含自定义类型
}

  3. 编译优化组合拳

    • 使用include限定src目录
    • 通过exclude排除node_modules
    • 启用incremental: true提升编译速度

五、总结

理解paths、types、include的差异需要抓住三个关键维度：

维度 paths types include
控制目标 模块解析路径 全局类型范围 文件处理范围
配置层级 compilerOptions compilerOptions 根级属性
影响阶段 编译时类型检查 类型推导阶段 编译输入阶段

通过精准配置这三个参数，开发者可以实现：
✅ 更清晰的模块导入路径
✅ 更可控的全局类型环境
✅ 更高效的编译过程

❌
❌