[Bug]: 关于 reset.scss 中全局 font-size 设置破坏了tailwind css的约定配置

[cvpv]

gin-vue-admin 版本

最新版本

Node 版本

V24

Golang 版本

go1.25

是否依旧存在

可以

bug描述

当前在 web/src/style/reset.scss 第 399 行设置了全局 font-size: 14px，这与项目使用的 UnoCSS 框架的tailwind预制样式产生了架构理念层面的冲突。

如果是无意为之，应该取消在html上定义font-size

• 核心问题： 所有基于 rem 的尺寸计算都被改变了基准，所有unocss内置的尺寸都和tailwind官网表现不符！比如text-base 在官网表现为16px而再这里表现为14px

大量UI开发者基于tailwind体系都默认1rem为4px，基于浏览器默认文字大小为16px的共识开发设计

搜索引擎搜索：

具体技术影响

内置尺寸系统错乱

/* 开发者期望 */
.w-16 { width: 4rem; /* 64px */ }

/* 实际效果 */
.w-16 { width: 4rem; /* 56px - 被缩小了 */ }

修改建议

推荐方案： 移除html上面的 font-size: 14px，改为在 body 元素或 UnoCSS 配置中管理

优势：

• 恢复 UnoCSS 标准尺寸系统
• 提升开发效率和代码可读性
• 符合现代前端最佳实践
• 保持本项目整体 14px 字体偏好

[cvpv]

下面是举例

标准布局写法

<div class="mx-auto w-full md:max-w-5xl">主要内容</div>

这是前端开发的经典布局模式：小屏内容撑满，中屏及以上最大宽度 1024px 并水平居中。

问题：尺寸偏差

预期效果： max-w-5xl = 1024px
实际效果： max-w-5xl = 896px（缩水 128px）

原因： 全局 font-size: 14px 导致所有 rem 计算基准变化

• 5xl = 4rem × 16px = 1024px（标准）
• 5xl = 4rem × 14px = 896px（当前）

影响范围

所有尺寸类都按 14/16 = 0.875 比例缩小：

类名	预期值	实际值	偏差
p-6	24px	21px	-3px
gap-4	16px	14px	-2px
h-12	48px	42px	-6px
text-lg	18px	15.75px	-2.25px

1. 学习成本增加：新人按tailwind官方文档学习，实际效果对不上
2. 调试时间浪费：需要心算换算，或者反复调试尺寸

[cvpv]

再举个例子字体大小类名混乱

标准字体使用

<h1 class="text-4xl font-bold">主标题</h1>
<h2 class="text-3xl font-semibold">二级标题</h2>
<h3 class="text-2xl font-medium">三级标题</h3>
<p class="text-base">正文内容</p>
<span class="text-sm text-gray-600">提示信息</span>
<div class="text-xs text-gray-500">时间戳</div>

类名	标准值	当前值	偏差	视觉效果
text-xs	12px	10.5px	-1.5px	过小，难以阅读
text-sm	14px	12.25px	-1.75px	提示文字偏小
text-base	16px	14px	-2px	正文显得局促
text-lg	18px	15.75px	-2.25px	副标题不够突出
text-xl	20px	17.5px	-2.5px	小标题层次感弱
text-2xl	24px	21px	-3px	三级标题缺乏层次
text-3xl	30px	26.25px	-3.75px	二级标题显得平淡
text-4xl	36px	31.5px	-4.5px	主标题不够醒目

现在所有的内置默认字体都变成非整数值了，我觉得的很不妥

[pixelmaxQm]

我们会在发出正式版之前确认这个问题，感谢建议

[Azir-11]

感谢您提出这个问题

关于当前 font-size 设置的考量

1. 设计初衷与实践验证

在 gin-vue-admin 的第一个版本设计时，我们经过充分的 UI 测试和用户体验评估，选择了 14px 作为基准字体大小。这个决定基于以下几个方面：

• 视觉和谐性：14px 在中文界面中提供了更好的阅读体验，特别是在管理后台这种信息密度较高的场景下
• 组件生态适配：经过大量的组件测试，14px 基准下各个 UI 组件的表现更加协调统一
• 实际项目验证：基于这个字体基准已经成功交付了大量的企业级项目，用户反馈良好

2. 向下兼容性考虑

您提到的 rem 基准问题确实存在，但需要考虑以下现实情况：

• 现有生态影响：目前已有数千个基于 gin-vue-admin 构建的项目在生产环境运行
• 迁移成本：如果在小版本更新中修改这个基准，会导致所有现有项目的 UI 布局发生变化
• 稳定性原则：根据语义化版本管理规范，这种影响面较大的修改应该在主版本升级时进行

3. 当前解决方案建议

如果您的项目需要严格遵循 Tailwind CSS 的标准尺寸体系，可以考虑：

/* 在您的项目中覆盖这个设置 */
html {
  font-size: 16px !important;
}

或者在 UnoCSS 配置中自定义 rem 基准：

// uno.config.js
export default {
  theme: {
    fontSize: {
      base: '16px', // 覆盖默认基准
    }
  }
}

未来规划

我们将这个特性视为 gin-vue-admin 的一个设计特色。在未来可能的大版本更新或 UI 架构重构中，我们会重新评估这个设计决策，届时会充分考虑社区的反馈和最新的前端最佳实践。

再次感谢您的详细反馈，这对项目的持续改进非常有价值！

[cvpv]

确实，这主要是个人开发偏好的问题。

不过我想建议我们更贴近UnoCSS官方的设计哲学。官方推荐使用他们的重置包，比如 @unocss/reset 或 @unocss/reset/tailwind-compat.css 来保持与官方生态的兼容性。

目前虽然我们引入了Tailwind 3预设包（@unocss/preset-wind3），但缺少了Tailwind默认提供的内置样式兼容性。

举个例子，直接使用 border 是没有效果的，因为这些基础样式定义在Tailwind的重置样式中：

*, ::after, ::before {
    box-sizing: border-box;
    border-width: 0;
    border-style: solid;
    border-color: #e5e7eb;
}

这意味着开发者需要使用 class="border border-solid" 而不是更直观的 class="border"。

这些细微差异可能会影响AI的开发模式和整体的开发体验。虽然这些确实是实现细节和偏好问题，但为了与更广泛的生态系统保持一致性，可能值得考虑。

当然，如果项目不需要处理这些边界情况，当前的方案完全没问题。

[cvpv]

关于我突然提到border样式问题，想补充说明一下这个细节：

从UnoCSS最新的PresetWind4可以看出一个重要趋势：官方已经将Tailwind的重置样式直接集成到预设中。根据官方文档明确表示：

"In PresetWind4, we align the reset styles with tailwind4 and integrate them internally. You don't need to install any additional CSS reset package like @unocss/reset or normalize.css."

这个决策说明UnoCSS团队从"可选依赖"改为"内置集成"，说明他们认为Tailwind重置样式已经从辅助工具升级为核心依赖。

如果连UnoCSS官方都认为Tailwind重置样式重要到需要内置集成，那说明这些基础样式确实是框架正常工作的重要保障之一。

这些都是我使用cursor实际辅助开发遇到的细节问题。

既然本项目的核心优势之一就是AI辅助开发，那么像border这样看似微小但影响AI开发体验的细节，可能值得在未来的迭代中考虑。

我注意到项目也是最近才从其他方案迁移到UnoCSS，那之前按照tailwind开发的代码，如果升级了业务代码才会才会出现大量问题，或许现在需要考虑这些细节。

[Azir-11]

border 的问题已经解决，全局 fs 的增强请求会在下一个大版本中得到应用