两周做成一个 bra size 计算器：纯静态部署与尺码计算逻辑

最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/

整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。

做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。

记录一下过程中比较值得分享的几个地方。

一、为什么选这个方向？

一开始并没有直接写代码，而是先看关键词。

美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：

• bra size calculator
• band size calculator
• sister size calculator
• bra size conversion

这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。

主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。

所以我选择先从细分需求入手。

比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。

这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。

这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。

关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。

二、尺码计算逻辑，比写页面麻烦多了

这是整个项目里我觉得最值得花时间研究的部分。

内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。

我在实现时，主要处理了下面几个问题。

1. 统一计算单位

内部计算以英寸为基准。

如果用户输入的是厘米，先转换成英寸：

inches = cm / 2.54

这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。

显示结果时再根据用户选择的单位进行转换。

2. Band size 怎么取？

这里采用下胸围取最近偶数的规则。

例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。

这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。

3. Cup size 怎么算？

基本思路是用上胸围与下胸围之间的差值作为参考：

差值 = 上胸围 − 下胸围

然后根据差值映射到对应的罩杯。

我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。

这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。

4. 姊妹码怎么换算？

姊妹码（Sister Sizes）的基本规律是：

• Band 增加 2，Cup 字母通常向下调整一级。
• Band 减少 2，Cup 字母通常向上调整一级。

例如，34C 的姊妹码通常包括 32D 和 36B。

原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。

实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。

5. 最麻烦的是 plus-four 算法

我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。

一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。

这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。

如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。

因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。

这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。

目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。

选择这套方案，主要有几个原因：

1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。

另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。

一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。

如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。

对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。

四、部署和 SEO 过程中踩过的坑

纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。

1. www 和裸域的统一

例如：

• brascale.com
• www.brascale.com

如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。

所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。

这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。

2. Sitemap 和规范 URL

Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。

我在处理 URL 时也特别关注了尾斜杠的一致性。

严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果 /page 和 /page/ 的处理不统一，就可能出现重复 URL、重定向链或者错误的规范地址。

因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。

3. 纯静态网站也需要考虑 SEO

工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。

所以每个页面除了计算器本身，还需要清楚地解释：

• 这个工具解决什么问题；
• 输入的数据应该如何测量；
• 计算结果是怎么得出的；
• 结果有哪些局限；
• 用户接下来可以做什么。

这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。

五、接下来准备观察什么？

网站上线只是第一步，接下来更值得关注的是实际数据。

我比较关心几个问题：

• 细分关键词能不能带来真实的搜索流量；
• 用户更常使用主计算器，还是某个具体的细分工具；
• 搜索用户进入页面后，是否真的完成计算；
• 哪些页面值得继续投入时间优化。

对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。

如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。

目前先把第一版跑起来，后续再根据真实反馈迭代。

网站放这里： https://brascale.com/

如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？