上周有个做前端的 A 同学把一段旋转动画的参数甩给我说“明明只转了 45 度方块为什么歪成这样”。我看了一眼他的代码顺手让他搜一下 cos45度等于多少结果他回我一串关键词cosin等于多少_cos45度等于多少。这个搜索串其实特别典型——一半是拼写手滑cosin 是 cosine 的常见错拼一半是真正的疑问cos45° 到底等于几这个数是怎么来的我该保留几位小数。先给结论cos45° √2/2 1/√2 ≈0.7071067811865476cosin 不是一个新函数它就是 cosine余弦被敲快了的结果。这个看起来只有初中难度的问题实际在图形开发、嵌入式、数据分析、结构放样里天天被翻出来翻车率还相当高——有人把角度和弧度搞混算出 0.5253有人把小数值截成 0.7 导致装配偏了几毫米。这篇就把这个搜索词彻底拆干净值和推导、精度怎么取、代码里怎么写、算错了怎么查不管你是刚学三角函数的还是十年没碰数学突然要在项目里用一下的都能直接抄走。1. 先把问题拆开cosin 是什么cos45° 又是什么1.1 “cosin” 不是新函数是 cosine 的手滑写法搜索词里出现 cosin 的频率高得惊人我第一次看到还以为是什么冷门记号。查下来发现它基本就是 cos sin 两个词在键盘上打架的产物或者是英文 cosine 拼漏了最后一个 e。在数学里没有叫 cosin 的独立函数正规写法只有三种cos缩写、cosine全称、cos θ带自变量。真正容易混的是 cos 和 sin 本身而不是拼写。你要记住的只有一句话cos 管的是“挨着角的边”sin 管的是“对着角的边”两者都除以斜边。中文里“余弦”的“余”字其实就在暗示它是“剩下的那条边”——你对着角看对着的那条是正弦的剩下挨着的那条就是余弦的。这个区分在写代码时尤其要命。我做图形项目时见过不少把旋转矩阵里 sin 和 cos 位置写反的案例表现是图形旋转方向拧了、或者运动轨迹变成椭圆。矩阵里第一行第一列是 cos第一行第二列是 -sin这个位置关系是死的记错一个符号整个坐标系就跟着错。所以当你搜“cosin 等于多少”的时候先把提问对象确认清楚你要的是余弦不是正弦也不是正切。这三个在 45° 这个特殊角上恰好有两个值撞在一起更容易掩盖错误——sin45° 和 cos45° 都是 0.7071你写错了也看不出来直到换到 30° 或 60° 才暴雷。1.2 cos45° 的准确值√2/2以及它的三种等价写法cos45° 的精确值是 √2/2做一个简单除法√2 ≈ 1.41421356237除以 2 得0.7071067811865476。它还有几个完全等价的写法不同场合用不同形式别被它们绕晕写法数值常见使用场合√2/20.70710678…教科书答案、公式推导、手算1/√20.70710678…电学、信号处理、归一化系数0.70710.7071工程图纸、快速估算0.707106780.70710678一般编程常量sin(π/4)0.70710678…代码里最常见的实际调用形式为什么会有两种写法因为 √2/2 是把分母有理化之后的结果1/√2 是没有理化的原始形态。数值上它们一模一样只是 1/√2 在推导时更自然——比如单位正方形对角线的长度是 √2把它投影到坐标轴上每一段就是 1/√2 乘以斜边长度。顺便把 45° 附近几个常用角的值列全这几个数在项目里出现的概率加起来能占到九成值得直接记住角度弧度sincostan0°001030°π/6 ≈ 0.52360.5√3/2 ≈ 0.8660√3/3 ≈ 0.577445°π/4 ≈ 0.7854√2/2 ≈ 0.7071√2/2 ≈ 0.7071160°π/3 ≈ 1.0472√3/2 ≈ 0.86600.5√3 ≈ 1.732190°π/2 ≈ 1.570810无穷注意 45° 那一行sin 和 cos 完全相等tan 恰好等于 1。这三个“整”是 45° 独有的性质也是它在工程上被大量使用的原因斜率和投影长度在 45° 时相等算起来最省事。比如做倒角C1 的 45° 倒角两个方向切掉的量一样做坡度45° 坡对应的坡度比正好是 1:1。2. 为什么偏偏是 √2/2三条推导路线最后都落到同一个数2.1 走几何等腰直角三角形里邻边比斜边最直观的路子是从直角三角形出发。余弦的定义是“角的邻边长度除以斜边长度”。45° 意味着这个直角三角形还有一个角是 45°因为三个角加起来 180°直角占 90°两个锐角相等那么它们对的边也相等这就是一个等腰直角三角形。设两条直角边长度都是 1。根据勾股定理斜边 √(1² 1²) √2。取其中一个 45° 角它的邻边就是长度为 1 的那条直角边于是 cos45° 邻边 / 斜边 1 / √2。分子分母同乘 √2得到 √2/2。这条推导最关键的一步是“设直角边为 1”。这一步之所以能随便设是因为三角函数只看比例不看绝对大小——你把三角形放大十倍边长都变成 10 和 10√2比值还是 1/√2。这就是为什么三角函数能用来描述角度而不受尺寸影响也是它在图纸缩放、地图投影、屏幕适配里通用的根本原因。注意初学者最常见的错误是把邻边和斜边认反尤其是在图上角画在右边的时候。判断方法是从这个角出发沿着两条边往外走不是斜的那条就是邻边斜对着直角的那条永远是斜边。2.2 走单位圆把“比”变成“坐标”直角三角形只适用于 0° 到 90°一旦角度超过 90° 或者变成负数定义就撑不住了。工程上更通用的是单位圆定义在坐标平面上画一个半径为 1 的圆从原点出发沿逆时针方向转 θ 角与圆交于一点 P那么P 的横坐标就是 cos θ纵坐标就是 sin θ。45° 的时候点 P 的横纵坐标相等因为 45° 这条射线就是 y x同时又落在单位圆上所以 x² y² 1。代入 x y得 2x² 1x 1/√2 √2/2。到这里和几何推导完全一致但它顺手解决了直角三角形解决不了的问题cos120° -0.5 这种负值怎么来的看横坐标在左侧就是负的一目了然。单位圆这套定义在代码里对应得很直接。做图形旋转的时候一个点绕原点转 θ 度新坐标就是 (x·cosθ - y·sinθ, x·sinθ y·cosθ)本质就是把点的极坐标角度加上 θ。我调试旋转逻辑的时候有个很省事的自检手段拿点 (1, 0) 转 45°结果应该是 (0.7071, 0.7071)长度仍然是 1。如果算出来长度不是 1那肯定是矩阵写错了或者把 sin/cos 用反了。2.3 走级数计算器内部其实在算多项式前面两条路告诉你“答案是什么”但计算器按一下就出 0.7071067811865476它是怎么算的答案是泰勒级数。余弦的展开式是cos x 1 - x²/2! x⁴/4! - x⁶/6! x⁸/8! - …这里的 x 必须是弧度。45° 换成弧度是 π/4 ≈ 0.7853981634。我实际算了一遍看每一轮加进去之后的结果累加到第几项计算结果与真值 0.7071067812 的差值1 - x²/2!0.69157491.55 × 10⁻² x⁴/4!0.70742923.2 × 10⁻⁴- x⁶/6!0.70710323.6 × 10⁻⁶ x⁸/8!0.7071068约 5 × 10⁻⁸可以看到收敛得非常快算到 8 次方这一项时7 位有效数字已经全部正确。这也是为什么很多嵌入式库压根不存三角函数表直接用四五项泰勒展开就够了——运算量比查表加插值还小。这条路线还有个副产品它解释了为什么角度一旦超过一定范围直接用级数会精度崩掉。x 越大x 的高次幂增长越快需要更多项才能收敛。所以正规实现都会先把角度规约到 [-π/4, π/4] 区间内再展开这一步叫“参数规约”是很多数值库出 bug 的重灾区。你自己手写实现的话别省这一步。3. 从 0.7071 到工程可用精度、单位、有效数字3.1 保留几位才够按场景选精度我见过两种极端一种是全篇写 0.7071 就完事结果做精密装配时累积误差肉眼可见另一种是把 0.7071067811865476 一路抄下去代码里一串 16 位小数可读性极差还没意义。到底保留几位取决于你拿它干什么使用场景建议精度理由口算、估量、草图0.7误差 1%对整体判断无影响手算题目、课堂作业√2/2 或 0.7071保留 4 位足够写精确值更好一般业务代码0.70710678双精度下 8 位有效数字够用图形渲染、游戏用库函数直接算不要手写常量精密测量、结构放样保留到实际有效位数取决于测量工具本身的精度嵌入式定点数Q15 下取 23170见后文定点数一节举个具体的量级感如果一个 100 毫米的零件用 0.7071 代替 0.70710678单次误差约 0.0000068 毫米也就是 6.8 纳米完全不用管。但如果这个系数要在一个循环里累积一万次误差可能放大到 0.068 毫米那就得看你的公差了。还有一点值得说不要自己手写 0.70710678 这种常量去替代库函数除非你有明确理由。库函数的实现经过了极端值、大角度、负角度的完整测试你自己写的常量只覆盖了 45° 这一个点一旦输入不是 45° 就抓瞎。手写常量只在一种场景下合理你知道角度永远是 45°且不想引入额外的计算开销。3.2 度与弧度90% 的“算出来不对”都出在这这是我在实际项目里见得最多的坑没有之一。你写cos(45)很多语言会返回0.5253219888177297而不是 0.7071。为什么因为编程语言里的三角函数默认吃弧度45 弧度不是 45 度。45 弧度到底是多少度45 ÷ (2π) ≈ 7.162 圈也就是转了 7 整圈再转过 0.162 圈换算成弧度就是 45 - 7×2π ≈ 1.0177 弧度约等于 58.3°。cos58.3° ≈ 0.5253和计算结果完全对得上。这个换算过程建议你自己手算一遍比背十遍“要用弧度”管用。正确的写法是先把角度换成弧度45 × π / 180 π/4 ≈ 0.7853981634再传给函数。Excel 里对应的是COS(RADIANS(45))直接写COS(45)同样是 0.5253。计算器就更隐蔽了屏幕上有个小小的 DEG / RAD 标记切错了算出来就是这个数很多人以为是计算器坏了。记住一句口诀微积分和编程默认弧度图纸和日常对话默认角度。跨过这条线就要显式换算不要指望任何默认值。顺带说个反向的坑有些老代码里存的是“度 × 100”这种整数表示比如 4500 代表 45°换算时要先除以 100 再转弧度漏掉一步就是几千倍的误差。3.3 特殊角的记忆法不用死背表很多人记不住 30°、45°、60° 的值其实没必要硬背。正弦那一行按 0°、30°、45°、60°、90° 的顺序分子依次是 √0、√1、√2、√3、√4统一除以 2 就是答案0、0.5、0.7071、0.8660、1。余弦就是把这一行倒过来读1、0.8660、0.7071、0.5、0。正切是 sin 除以 cos45° 时两者相等所以是 1。这个规律的妙处在于它是“长”出来的不是“背”出来的。你只要记住“分子开根号、分母是 2”这一条五行数据就全在手上。真忘了也不要紧45° 直接回到等腰直角三角形现场推两分钟的事比翻表快。另一个我常用的记忆锚点0.7071 这个数在工程里到处都能碰到。它是正方形对角线和边长的比值的倒数、是半功率点-3dB对应的归一化系数、是很多滤波器系数的标准值。你在不同领域反复看到同一个数字自然就记住了。4. 代码与工程现场cos45° 真正被用在哪里4.1 三种常见语言里的调用与坑写代码算余弦语法差不多坑却各不相同。我整理了常用的几种import math # 正确先转弧度 print(math.cos(math.pi / 4)) # 0.7071067811865476 print(math.cos(math.radians(45))) # 0.7071067811865476 # 错误直接传角度 print(math.cos(45)) # 0.5253219888177297 # 常量和库函数混用时的写法 COS_45 math.sqrt(2) / 2 # 0.7071067811865476// JS 同样只吃弧度 console.log(Math.cos(Math.PI / 4)); // 0.7071067811865476 console.log(Math.cos(45)); // 0.5253219888177297 console.log(Math.cos(45 * Math.PI / 180)); // 0.7071067811865476#include math.h #include stdio.h int main(void) { double a cos(M_PI / 4); /* 0.7071067811865476 */ double b cos(45.0 * M_PI / 180); /* 0.7071067811865476 */ double c cos(45.0); /* 0.5253219888177297 */ printf(%.16f\n%.16f\n%.16f\n, a, b, c); return 0; }C 这边要注意两件事一是编译时通常要加-lm链接数学库否则会报未定义引用二是M_PI严格来说不是标准 C 的一部分某些编译器要开_USE_MATH_DEFINES或者在 C99 以上的特定配置下才可见。稳妥的写法是自己定义#define PI 3.14159265358979323846省得换平台就编译不过。还有一个隐蔽的差异不同语言返回的末位可能不完全一样。Python 和 JS 在 45° 上都返回 0.7071067811865476但某些平台的实现可能返回 …4758。这不是 bug是浮点数本身的表示限制正常比较时不要用用差值小于 1e-9 判断。4.2 图形旋转、向量夹角与相似度计算45° 这个角在图形里出现的频率极高因为它是“斜着放”的最自然选择而且旋转矩阵的四个元素里有三个幅值相等调试时容易对照。一个点 (x, y) 绕原点逆时针转 θ 后的坐标是import math def rotate(x, y, deg): t math.radians(deg) c, s math.cos(t), math.sin(t) return x * c - y * s, x * s y * c print(rotate(1, 0, 45)) # (0.7071067811865476, 0.7071067811865475)拿 (1, 0) 验证转 45° 之后横纵坐标相等都约等于 0.7071长度平方 0.5 0.5 1没变形。这个自检我每次写旋转都要跑一遍能挡掉一大半低级错误。向量夹角是另一个高频场景。两个向量的余弦相似度就是 cos θ (a·b) / (|a|·|b|)。夹角 45° 时这个值是 0.7071意味着两个方向“比较像但不完全一样”。做文本相似度、推荐召回、特征匹配时0.7 上下通常是个分水岭——低于 0.7 就认为相关性不够。这个阈值不是随便定的它恰好对应 45° 的方向偏差超过 45° 就说明两个向量在半数以上的维度上已经走偏了。还有个容易忽略的点45° 旋转在图像处理里是最难插值好的角度之一。90° 的整数倍旋转只是像素搬运没有精度损失45° 之后每个目标像素都落在四个原像素之间必须做双线性或双三次插值边缘会明显变软。我处理扫描件的时候宁可先转 90° 再微调 ±5°把 45° 这种大角度旋转放到最后一步做就是为了少一次重采样。4.3 嵌入式与定点数23170 这个数字的来历在单片机、电机控制这类没有浮点单元或者浮点太慢的场景cos45° 会被存成定点数。最常用的是 Q15 格式把 [-1, 1] 映射到 [-32768, 32767] 的整数区间0.70710678 × 32768 23170.475四舍五入取23170反算回浮点23170 / 32768 0.707092285误差约 1.45 × 10⁻⁵如果你翻过电机矢量控制FOC的源码会频繁看到 23170 这个常数它就是 √2/2 的 Q15 表示。同样常见的是 163840.5、28378√3/2 ≈ 0.866这些。这类实现通常还会配一张 0 到 90° 的正弦表按 256 或 1024 个点等分查表加线性插值比调用浮点库快一个数量级。用定点数有几个必须注意的地方我踩过乘法之后要右移 15 位还原忘记移位是最常见的错结果会大 32768 倍。两个 Q15 数相乘中间结果会超出 32 位要用 int64 或者拆成高低位算直接乘会溢出变负数。负数的舍入方向要统一对负数是向下取整跟 0.5再取整的结果不一致混用会导致 ±1 的抖动。提醒定点数的误差是累积的。单次 1.45 × 10⁻⁵ 看着无所谓但如果它在积分环节里被累加几千次就可能变成肉眼可见的漂移。做闭环控制时我一般会定期把积分项拉回浮点重新校准一次。5. 排查实录结果不对时按这张表逐条对5.1 六类高频错误与定位方法算余弦算错八成跑不出下面六种情况。我把它整理成一张速查表出问题的时候按顺序过一遍基本能定位到现象最可能原因快速验证方法得到 0.5253 左右传了角度没转弧度输入改成 0.7854 再试一次得到 0.8660把 cos 写成了 sin 但不自知换 30° 试cos30 应是 0.866若得 0.5 则 sin/cos 反了得到 -0.7071角度放错了象限检查是 45 还是 135、225得到 0.707 但符号/方向错旋转矩阵里 -sin 的位置写反拿 (1,0) 转 90° 看是否得 (0,1)图形尺寸越转越大或越小忘了归一化或半径没乘对算旋转后向量长度是否为 1定点数结果大得离谱乘法后没右移结果除以 32768 看是否合理这张表里我最想强调的是第二行。sin 和 cos 在 45° 上相等所以拿 45° 做测试根本区分不出来你写没写反必须换到 30° 或 60° 才能暴露。做单元测试的时候45° 只能验证“数值对不对”验证不了“函数选对没选对”这两个断言得分开写。还有个更隐蔽的某些老的计算库角度是顺时针为正或者 0° 指向不是正右方而是正上方。这类差异在 45° 上表现为结果符号不同很容易被当成程序 bug 查半天。接手新库的时候我第一件事就是画个 0°、90°、180° 的基准点验证坐标系比读文档快。5.2 我自己踩过的三个坑第一个坑是单位混用。有个批处理脚本里角度从配置文件读进来是度我图省事直接丢给 Math.cos跑了三个月没人发现因为那个角度恰好一直是 0cos0 1两种单位下都是 1。直到有人配了个非零角度整个结果全歪。教训是函数入口处就把单位写进参数名里比如angleDeg、angleRad比写注释管用得多。第二个坑是常量精度。早期为了省事我在一个坐标转换里写了0.71单次看没问题。后来这个转换在一次渲染里被调用了四十多次逐层嵌套误差滚到肉眼可辨的偏移查了两天才发现根源是一个两位小数。从那以后我的规矩是只要这个数会参与多次运算就用库函数或者至少八位有效数字。第三个坑是边界值。cos 在 90° 附近对输入极其敏感角度差 0.01° 结果就变了 0.00017。我在做姿态解算时一度以为陀螺仪在漂最后发现是角度输入只保留了 2 位小数量化误差被 cos 的陡峭段放大了。处理办法是那个区间改用 sin 计算再转换避开敏感区。说到底cos45度等于多少 这个问题本身一点都不难难的是搞清楚“我现在到底在哪个单位制里、需要几位精度、这个数是拿来做判断还是做累加”。这三件事想清楚了0.7071 这个数才能真正为你所用而不是变成下一个 bug 的来源。我自己现在的习惯是看到任何三角函数相关的代码先花十秒找单位换算那一行——找到了再往下读找不到就先补上。
