前言

所谓语义化版本控制，就是要求你的版本号能按照特定规则及条件来进行约束，以期达到见到版本号即能了解其修改内容的信息或相邻版本间的更新迭代关系。通过阅读本文，你将能够对语义化版本控制规范能够有一个全面的了解，同时也对各平台上依赖版本时的语法有个大体的了解。

背景

在正式开始之前，先问大家几个问题：

我们经常在类似 Github、npm、或者 pub.dev 上看到一些软件或者库的版本号包含如下信息，你是否会疑惑他们之间的区别是什么？分别适用什么场景？

• alpha


• beta


• rc


• release

再看看下面几组版本号，你是否能弄清楚各个版本号之间谁更新更大？

• 1.0.0 1.0.1 1.1.0


• 1.0.0-beta 1.0.0


• 1.0.0-release 1.0.0


• 1.0.0-alpha 1.0.0-alpha.1


• 1.0.0-alpha 1.0.0-rc.1

这次将借着我们在做组件管理平台的机会，像大家介绍一下日常软件开发中的语义化版本控制规范。相信通过下面的学习，上述的问题也能够迎刃而解。

常见先行版本号标识

上面说到 alpha、beta、rc、release 等版本号中常见的一些标识，有一个正式的名称叫做：先行版本号标识。我们可以通过一个生活中的例子来通俗易懂的说明它们之间的差异和联系。

现在假设你是一个蛋糕店的老板，你打算给你的蛋糕店推出一个新品，那么上述所谓的先行版本号就是如下几个阶段的蛋糕：

Alpha 版就是你对于你蛋糕的最终形式还在脑海当中，只有一个蛋糕的基本样子，口味应该是什么味道你心里还没谱，对于装饰如奶油、水果还有蜡烛这些甚至都还没有放在一起（你的软件各功能甚至都没有打通）。由于过于简陋，并且口味还没固定，你还不能将其给你的顾客品尝。你只能自己反复摸索尝试，或者让自己店里的员工对口味、外观以及一些缺陷进行点评。

Beta 版就是你的蛋糕已经开始尝试将部分奶油涂抹在蛋糕上，你已经尝试将所有的元素组装起来，这时候的蛋糕还处于不能拿出去卖的阶段，但口味和后续方向已经基本固定。你甚至可以邀请你店里的熟客来参加小规模的试吃活动，并让他们针对你的这款蛋糕进行全方面的点评。

RC 版就是你的蛋糕已经基本做完了，其最核心的口味和外观已经确定下来，你可以再检查一下蛋糕是否有裂缝、哪些地方需要针对性的进行一些美化或修补。

release 版就是你已经把蛋糕装饰好了，插上蜡烛，撒上曲奇，进行裱花。这时候蛋糕已经完成了，你可以正式的将这块蛋糕摆上橱窗，向大家兜售你的艺术品了。

通过上述的蛋糕制作过程，你应该对这些先行版本号标识有了自己的认知。接下来我们再总结下这些先行版本号标识的常见含义：

相信阅读到这里，上面的第一个问题你已经有了答案。那么明白这些标识的具体含义之后，它到底应该怎么用呢？具体要放在版本号里的哪个位置上呢？接下来我们将通过对语义化版本控制规范的详细介绍，来帮助你解答这些疑惑。

何为语义化版本控制规范

在介绍什么是语义化版本控制规范之前，我们先需要了解为什么需要语义化版本控制规范。

大家先设身处地的设想这样一个开发场景：

你现在的项目现在分别依赖了 foo : 1.0.0、bar : 2.0.0、baz : 3.0.0

同时 foo 组件也依赖了 bar : 2.0.0、baz : 3.0.0

同时 bar 组件也依赖了 baz : 3.0.0

现在你很幸运，项目可以跑起来。

突然有一天因为要修改一个问题，需要升级你项目中 baz 组件的版本号，需要将它从 3.0.0 升级到 3.0.1。但很不幸的是，baz 组件这个小小的版本升级却发生了破坏性的 API 改动。然后你发现你不仅需要修改主工程 example_app 的版本号，还需要升级 foo 组件的版本号以及 bar 组件的版本号。而在你做完这些之后，发现 foo 依赖的其他组件的版本又和你主工程 example_app 项目中依赖的组件的版本冲突了，于是你崩溃了。

这就是软件管理领域中被称作“依赖地狱”的死亡之谷。即当你的系统规模越大，引入的包越多，你就越可能遇到由于依赖导致的问题：

• 如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）


• 而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量） 当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。

通过上述的场景我们可以看到，版本号的管理（包括依赖关系的控制以及版本号的命名）并不是一个随心所欲的事情：管理好了，能给你带来极大便利，反之则会给你的开发带来很多没必要的麻烦。那么我们应该如何解决这些事情呢？

基于上述的一些问题，Gravatars 及 Github 的创始人之一的 Tom Preston-Werner 提出了一个名为语义化版本控制规范（Semantic Versioning）的解决方案，它期望用一组简单的规则及条件来约束版本号的配置和增长。这套规则是根据现在各种封闭、开源软件所广泛使用的版本号命名规则所设计。为了让这套理论运作，必须要定义好你的公共 API。一旦定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

0. 主版本号：当你做了不兼容的 API 修改


1. 次版本号：当你做了向下兼容的功能性新增


2. 修订号：当你做了向下兼容的问题修正

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

以上这套规则或者说系统，就是所谓的”语义化版本控制”，在这套规则之下，版本号以及版本号的更新都潜在包含了代码的修改信息，而这套规则被简称为 semver (Semantic Versioning 简写)。

接下来我将基于 semver 2.01 向大家介绍 这套规则的一些细则。

语义化版本控制规范细则

语义化版本控制规范的细则有很多，有兴趣的同学可以直接到semver 2.01 的官方文档 查看即可，我们这里将其主要内容总结给大家。

X.Y.Z（主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

其实所谓语义化版本控制规范，本来也只是一种约定，它并不能完美适合每一个团队，我们也没必要完全生搬硬套，这里以 Google 官方推出的 mockito2 的版本号为例，可以看到其也没有严格按照细则进行遵守。

所以如果你团队内已经统一认知，了解版本号中每个地方代表的含义，做到“见号知意”：看到 1.0.0-npeFixed.8 就知道这个组件是从 1.0.0 拉出来 为了修复 NPE 的；看到 2.3.0-addFaceIdSupport.1 就知道这个组件是基于 2.3.0 来做 FaceId 支持的；见到 5.0.0-nullSafety.6 就知道这个版本是为了空安全的。那么我们的语义化版本控制规范的目的也就达到了，不是吗？

版本语法

就像人类的烹饪方式从最开始的单纯用火烤到发明陶器之后的烹煮，再到现代社会中基于烤、煮、蒸而演化出来的各类五花八门的烹饪方式一样，语义化版本控制规范在各个平台上也衍生出不同的版本规范和版本语法（Version Syntax），但万变不离其宗。接下来我将大致介绍下常见平台版本语法的异同，期望能对你有所帮助。

由于 PyPI上的版本规范及版本说明符比较特殊且繁琐，这里就不进行比对，有兴趣的同学可以查看PEP 440 – Version Identification and Dependency Specification3 了解更多细节。

有些平台中还有一些特定的其他语法和规则，如果感兴趣，可以点击平台名称的超链接进入对应平台的官方文档自行查看。

相信你读到了这里，对语义化版本控制规范已经了然于胸。那么开篇的两个问题你是否也有了答案，欢迎在评论区留言。

Q&A 环节

经过上面的分享，相信大家对语义化版本已经有了一个整体的了解，那么我们来检验一下你的学习效果，请尝试回答下面几个问题：

Q：“v1.2.3” 是一个语义化版本号吗？

首先，“v1.2.3” 并不是的一个语义化的版本号。但是，在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中，将 “version” 缩写为 “v” 是很常见的。但是我们可以通过 npm-semver 来进行处理并转化成语义化的版本。

Q：这么多规则及要求，我该如何验证我的语义化版本是否符合规范或者比较他们之间的大小关系呢？

这里就推荐 npm 的 github.com/npm/node-se…

对于脚本上对版本是否符合要求进行验证，可以使用 semver 2.0 文档中推荐的如下两个正则表达式。

第一个用于支持按组名称提取的语言，PCRE（Perl 兼容正则表达式，比如 Perl、PHP 和 R）、Python 和 Go。参见： regex101.com/r/Ly7O1x/3/

/^(?P0|[1-9]\d*).(?P0|[1-9]\d*).(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:+(?P[0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?$/gm

第二个用于支持按编号提取的语言（与第一个对应的提取项按顺序分别为：major、minor、patch、prerelease、buildmetadata）。主要包括 ECMA Script（JavaScript）、PCRE（Perl 兼容正则表达式，比如 Perl、PHP 和 R）、Python 和 Go。 参见： regex101.com/r/vkijKf/1/

/^(0|[1-9]\d ).(0|[1-9]\d).(0|[1-9]\d )(?:-((?:0|[1-9]\d|\d*a-zA-Z-)(?:.(?:0|[1-9]\d |\da-zA-Z- )) ))?(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)))?$/gm

Q：万一不小心把一个不兼容的改版当成了次版本号发行了，或者在修订等级的发布中，误将重大且不兼容的改变加到代码之中，我能通过重复发布当前版本来解决问题吗？

首先必须强调一点，不管如何都不能去修改已发行的版本（这点在部分平台已经帮你处理掉了，例如 pub 本身已经做了这种限制）。然后最好根据场景升级一个对应级别的版本来回滚逻辑，最后再将你的重大且不兼容的改版升一个主版本号进行发布。记住，语义化的版本控制就是透过版本号的改变来传达意义。

尾声

至此，我们已经了解了语义化版本控制规范的具体细则，常用的先行版本号标识的含义及应用场景，希望能在大家日后的工作生活当中所有帮助。你还见过哪些常见的先行版本号，你们团队又是如何避免包依赖地狱的，欢迎在评论区补充。感谢大家的观看，再见。

起因

大约一个月前，在学校大病一场（不知道是不是🐑了，反正在学校每天核酸没检测出来）在宿舍休息了整整一周。当时因为发烧全身疼所以基本一直躺着刷刷视频。看了一周倪海厦老师讲的天纪，人纪感悟颇多，中华传统中一些优秀的东西竟然在现代教育下被丢失了而现在的人也只有在身体不得不休息的情况下才会停止内卷慢下来好好思考。

当然有人会说算命啥的都是封建迷信，作为接受了科学思想洗礼的新时代人慢慢也不再去接受那一套，在这里呢我不对这些想法做任何评价。信则有不信则无，存在即合理嘛。

因为疫情原因呢学校早早就给我们放了假，有了更多的空闲时间可以思考在学校没时间想的事情，做一些除开看论文、做项目之外的事

开始

前几天买的服务器刚好到家了，花了几天配置好环境（最重要的是花了大半天解决todesk、向日葵远程黑屏的问题）。今天下午写好代码丢到阳台让它自己慢慢训练去，剩下的时间就开始写今天关于算命的小程序。

六壬法

六壬法

根据倪师讲的，计算现在的农历日期加上时辰就可以推算当前某个想法适不适合去做。以大安开始每次从当宫开始顺时针数，下面是例子。

• 假如今天是农历十二月十号 子时

1. 
   

   首先从大安开始数1到12，结果是空亡

   
   


2. 
   

   再从空亡开始数1到10，结果是速喜

   
   


3. 
   

   然后从速喜开始子丑寅卯这样数，子是1

   
   


4. 
   

   所以上面例子最后的结果就是速喜

   
   

计算过程都理解了怎么写成代码呢。这里需要知道三个条件，农历的月日以及当前的时辰，农历的月日这个地方我借鉴了这篇博客【C/C++】:用C实现输出日期的阴历日子直接复制了主要内容，打表直接计算农历日期，只需要输入当前阳历的年月日。

然后当前时间转为十二时辰也很简单，首先得到当前的小时时间hour，那么十二时辰就是(hour+1)/2<12?(hour+1)/2:0;这里子时记为0。

整个程序如下：

#include<iostream>

#include<string>

#include<ctime>

#include<vector>



std::vector<std::string> MAP{"大安","留连","速喜","赤口","小吉","空亡"};



unsigned int LunarCalendarDay;  

unsigned int LunarCalendarTable[199] =  

{  

0x04AE53,0x0A5748,0x5526BD,0x0D2650,0x0D9544,0x46AAB9,0x056A4D,0x09AD42,0x24AEB6,0x04AE4A



,/*1901-1910*/  





0x6A4DBE,0x0A4D52,0x0D2546,0x5D52BA,0x0B544E,0x0D6A43,0x296D37,0x095B4B,0x749BC1,0x049754



,/*1911-1920*/  





0x0A4B48,0x5B25BC,0x06A550,0x06D445,0x4ADAB8,0x02B64D,0x095742,0x2497B7,0x04974A,0x664B3E



,/*1921-1930*/  





0x0D4A51,0x0EA546,0x56D4BA,0x05AD4E,0x02B644,0x393738,0x092E4B,0x7C96BF,0x0C9553,0x0D4A48



,/*1931-1940*/  





0x6DA53B,0x0B554F,0x056A45,0x4AADB9,0x025D4D,0x092D42,0x2C95B6,0x0A954A,0x7B4ABD,0x06CA51



,/*1941-1950*/  





0x0B5546,0x555ABB,0x04DA4E,0x0A5B43,0x352BB8,0x052B4C,0x8A953F,0x0E9552,0x06AA48,0x6AD53C



,/*1951-1960*/  





0x0AB54F,0x04B645,0x4A5739,0x0A574D,0x052642,0x3E9335,0x0D9549,0x75AABE,0x056A51,0x096D46



,/*1961-1970*/  





0x54AEBB,0x04AD4F,0x0A4D43,0x4D26B7,0x0D254B,0x8D52BF,0x0B5452,0x0B6A47,0x696D3C,0x095B50



,/*1971-1980*/  





0x049B45,0x4A4BB9,0x0A4B4D,0xAB25C2,0x06A554,0x06D449,0x6ADA3D,0x0AB651,0x093746,0x5497BB



,/*1981-1990*/  





0x04974F,0x064B44,0x36A537,0x0EA54A,0x86B2BF,0x05AC53,0x0AB647,0x5936BC,0x092E50,0x0C9645



,/*1991-2000*/  





0x4D4AB8,0x0D4A4C,0x0DA541,0x25AAB6,0x056A49,0x7AADBD,0x025D52,0x092D47,0x5C95BA,0x0A954E



,/*2001-2010*/  





0x0B4A43,0x4B5537,0x0AD54A,0x955ABF,0x04BA53,0x0A5B48,0x652BBC,0x052B50,0x0A9345,0x474AB9



,/*2011-2020*/  





0x06AA4C,0x0AD541,0x24DAB6,0x04B64A,0x69573D,0x0A4E51,0x0D2646,0x5E933A,0x0D534D,0x05AA43



,/*2021-2030*/  





0x36B537,0x096D4B,0xB4AEBF,0x04AD53,0x0A4D48,0x6D25BC,0x0D254F,0x0D5244,0x5DAA38,0x0B5A4C



,/*2031-2040*/  





0x056D41,0x24ADB6,0x049B4A,0x7A4BBE,0x0A4B51,0x0AA546,0x5B52BA,0x06D24E,0x0ADA42,0x355B37



,/*2041-2050*/  





0x09374B,0x8497C1,0x049753,0x064B48,0x66A53C,0x0EA54F,0x06B244,0x4AB638,0x0AAE4C,0x092E42



,/*2051-2060*/  





0x3C9735,0x0C9649,0x7D4ABD,0x0D4A51,0x0DA545,0x55AABA,0x056A4E,0x0A6D43,0x452EB7,0x052D4B



,/*2061-2070*/  





0x8A95BF,0x0A9553,0x0B4A47,0x6B553B,0x0AD54F,0x055A45,0x4A5D38,0x0A5B4C,0x052B42,0x3A93B6



,/*2071-2080*/  





0x069349,0x7729BD,0x06AA51,0x0AD546,0x54DABA,0x04B64E,0x0A5743,0x452738,0x0D264A,0x8E933E



,/*2081-2090*/  

    0x0D5252,0x0DAA47,0x66B53B,0x056D4F,0x04AE45,0x4A4EB9,0x0A4D4C,0x0D1541,0x2D92B5      



    /*2091-2099*/  

};  



int MonthAdd[12] = {0,31,59,90,120,151,181,212,243,273,304,334};  

int LunarCalendar(int year,int month,int day)  

{  

    int Spring_NY,Sun_NY,StaticDayCount;  

    int index,flag;  

    //Spring_NY 记录春节离当年元旦的天数。  

    //Sun_NY 记录阳历日离当年元旦的天数。  

    if ( ((LunarCalendarTable[year-1901] & 0x0060) >> 5) == 1)  

        Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1;  

    else  

        Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1 + 31;  

    Sun_NY = MonthAdd[month-1] + day - 1;  

    if ( (!(year % 4)) && (month > 2))  

        Sun_NY++;  

    //StaticDayCount记录大小月的天数 29 或30  

    //index 记录从哪个月开始来计算。  

    //flag 是用来对闰月的特殊处理。  

    //判断阳历日在春节前还是春节后  

    if (Sun_NY >= Spring_NY)//阳历日在春节后（含春节那天）  

    {  

        Sun_NY -= Spring_NY;  

        month = 1;  

        index = 1;  

        flag = 0;  

        if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

            StaticDayCount = 29;  

        else  

            StaticDayCount = 30;  

        while (Sun_NY >= StaticDayCount)  

        {  

            Sun_NY -= StaticDayCount;  

            index++;  

            if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) )  

            {  

                flag = ~flag;  

                if (flag == 0)  

                    month++;  

            }  

            else  

                month++;  

            if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

                StaticDayCount=29;  

            else  

                StaticDayCount=30;  

        }  

        day = Sun_NY + 1;  

    }  

    else //阳历日在春节前  

    {  

        Spring_NY -= Sun_NY;  

        year--;  

        month = 12;  

        if ( ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) == 0)  

            index = 12;  

        else  

            index = 13;  

        flag = 0;  

        if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

            StaticDayCount = 29;  

        else  

            StaticDayCount = 30;  

        while (Spring_NY > StaticDayCount)  

        {  

            Spring_NY -= StaticDayCount;  

            index--;  

            if (flag == 0)  

                month--;  

            if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))  

                flag = ~flag;  

            if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

                StaticDayCount = 29;  

            else  

                StaticDayCount = 30;  

        }  

        day = StaticDayCount - Spring_NY + 1;  

    }  

    LunarCalendarDay |= day;  

    LunarCalendarDay |= (month << 6);  

    if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))  

        return 1;  

    else  

        return 0;  

}  



void output(int year,int month,int day,int &d_month,int &d_day)

{

     const char *ChDay[] = {"*","初一","初二","初三","初四","初五",  

                           "初六","初七","初八","初九","初十",  

                           "十一","十二","十三","十四","十五",  

                           "十六","十七","十八","十九","二十",  

                           "廿一","廿二","廿三","廿四","廿五",  

                           "廿六","廿七","廿八","廿九","三十"  

                          };  

    const char *ChMonth[] = {"*","正","二","三","四","五","六","七","八","九","十","十一","腊"};

    char str[13] = "";

    strcat(str,"农历"); 

    if (LunarCalendar(year,month,day)){  

        strcat(str,"闰"); 

        d_month=(LunarCalendarDay & 0x3C0) >> 6;

        strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]);  

    }  

    else{

        d_month=(LunarCalendarDay & 0x3C0) >> 6;

        strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]); 

    } 

    strcat(str,"月");  

    d_day=LunarCalendarDay & 0x3F;

    strcat(str,ChDay[LunarCalendarDay & 0x3F]);  

    puts(str); 

}





int ChangeHourToPeriods(){

    time_t now=time(0);

    int hour;

    std::tm* t=std::localtime(&now);

    hour=(int)t->tm_hour;

    hour=(hour+1)/2<12?(hour+1)/2:0;

    return hour;

}





int main(){

    int year,month,day;

    std::cout<<"Please input the number of year,month,day:"<<std::endl;

    std::cin>>year>>month>>day;

    int d_month=0,d_day=0;

    output(year,month,day,d_month,d_day);

    int hour=ChangeHourToPeriods();

    int SumAll=d_month+d_day+hour-2;

    std::cout<<"The result is : "<<MAP[(SumAll%6)]<<std::endl;

    return 0;

}

因为每次从当宫开始数也就每次都少数了1，但是由于最后子时以0开始所以只减2。

测试结果(测试的时间是21点亥时)

占卦法

占卦法

还有傅佩荣教授的三组三位数占卦法，这个更多就是易经中的内容太过于深奥，所以直接说计算方法。

三组三位数分别代表下卦，上卦和爻，卦象的三位数对8取余爻对6取余，如果整除就记为除数本身。

然后再去六十四卦中复制打表，最后得到卦象以及爻

整体实现如下

#include<iostream>

#include<string>

#include<vector>





std::vector<std::string> TRIGRAM=std::vector<std::string> {"乾","兑","离","震","巽","坎","艮","坤"};

std::vector<std::string> TRIGRAMMAP {

    "乾为天","泽天夬","火天大有","雷天大壮","风天小畜","水天需","山天大畜","地天泰",

    "天泽履","兑为泽","火泽睽","雷泽归妹","风泽中孚","水泽节","山泽损","地泽临",

    "天火同人","泽火革","离为火","雷火丰","风火家人","水火既济","山火贲","地火明夷",

    "天雷无妄","泽雷随","火雷噬嗑","震为雷","风雷益","水雷屯","山雷颐","地雷复",

    "天风姤","泽风大过","火风鼎","雷风恒","巽为风","水风井","山风蛊","地风升",

    "天水讼","泽水困","火水未济","雷水解","风水涣","坎为水","山水蒙","地水师",

    "天山遁","泽山咸","火山旅","雷山小过","风山渐","水山蹇","艮为山","地山谦",

    "天地否","泽地萃","火地晋","雷地豫","风地观","水地比","山地剥","坤为地"



};



int main(){

    std::vector<int> LowToHigh(3);

    std::vector<std::string> results(3);

    std::cout<<"Input 3*xxx like(111,222,333),means from up to high"<<std::endl;



    for(int i=0;i<3;++i){

        std::cin>>LowToHigh[i];

    }

    

    LowToHigh[0]=LowToHigh[0]%8==0?8:LowToHigh[0]%8;

    LowToHigh[1]=LowToHigh[1]%8==0?8:LowToHigh[1]%8;

    LowToHigh[2]=LowToHigh[2]%6==0?6:LowToHigh[2]%6;







    for(int i=0;i<2;++i){

        results[i]=TRIGRAM[LowToHigh[i]-1];

    }

    results[2]=std::to_string(LowToHigh[2]);



    std::cout<<"下卦:"<<results[0]<<" 上卦:"<<results[1]<<" "<<results[2]<<std::endl;

    std::cout<<"卦象: "<<TRIGRAMMAP[(LowToHigh[0]-1)*8+LowToHigh[1]-1]<<std::endl;

}

这里测试的例子是视频中的数字

结尾

有的时候真的需要一些自己的沉淀时间，不能忘了最初的目标。写这篇Blog也并不是为了宣传封建迷信，而是希望让更多程序圈的人想想当初我们喜欢敲代码到底是为了什么？我们喜欢的是将代码作为工具实现一些有趣的功能，并不是为了水论文或者工作被迫的去东拼西凑弄出一些用处不大的东西。

好多想吐槽的话最终还是打了又删，无法改变现状的时候只能屈服于现状，我相信不止我一人如此。但是请不要忘了 潜龙勿用见龙在田，终日乾乾飞龙在天

刚入职，就踩大坑，相信有很多朋友有我类似的经历。

5年前，我入职一家在线教育公司，新的公司福利非常好，各种零食随便吃，据说还能正点下班，一切都超出我的期望，“可算让我找着神仙公司了”，我的心里一阵窃喜。

在熟悉环境之后，我趁着上厕所的时候，顺便去旁边的零食摊挑了点零食。接下来的一天里，我专注地配置开发环境、阅读新人文档，当然我也不忘兼顾手边的零食。

初出茅庐，功败垂成

"好景不长"，第三天上午，刚到公司，屁股还没坐热。新组长立刻给我安排了任务。他决定让我将配置端的课程搜索，从使用现有的Lucene搜索切换到ElasticSearch搜索。这个任务并不算复杂，然而我却办砸了。

先说为什么不复杂？

1. ElasticSearch的搜索功能 基于Lucene工具库实现的，两者在搜索请求构造方式上几乎一致，在客户端使用上差异很小。

2. 切换方案无需顾虑太多稳定性问题。由于是配置端课程搜索，并非是用户端搜索，所以平稳切换的压力较小、性能压力也比较小。

总的来说，领导认为这个事情并不紧急，重要性也不算高，而且业务逻辑相对简单，难度能够把握，因此安排我去探索一下。可是，我却犯了两个错误，把入职的第一件事办砸了。现在回过头来看，十分遗憾！

难以解决的bug让我陷入困境

将搜索方式从Lucene切换为ElasticSearch后，如何评估切换后搜索结果的准确度呢？

除了通过不断地回归测试，还有一个更好的方案。

我的方案是，在调用搜索时同时并发调用Lucene搜索和ElasticSearch搜索。在汇总搜索结果时，比对两者的搜索结果是否完全一致。如果在切换搜索引擎的过程中，两个方案的搜索结果不一致，就打印异常搜索条件和搜索结果，并进行人工排查原因。

在实际切换过程中，我经常遇到搜索数据不一致的情况，这让我感到十分苦恼。我花了一周的时间编写代码，然后又用了两周多的时间来排查问题，这超出了预估的时间。在这个过程中，我感到非常焦虑和沮丧。作为一个新来的员工，我希望能够表现出色，给领导留下好印象。然而事与愿违，难以解决的bug让我陷入困境。

经过无数次的怀疑和尝试，我终于找到了问题的根源。原来，我忘记了添加排序方式。

因为存在很多课程数据，所以配置端搜索需要分页搜索。在之前的Lucene搜索方式中，我们使用课程Id来进行排序。然而在切换到新的ElasticSearch方案中时，我忘记了添加排序方式。这个错误的后果是，虽然整体上结果是一致的，但由于新方案没有排序方式，每一页的搜索结果是随机的，无法预测，所以与原方案的结果不一致。

新方案加上课程Id排序方式以后，搜索结果和原方案一致。

为此，我总结了分页查询的设计要点！希望大家不要重复踩坑！# 四选一，如何选择适合你的分页方案？

千万不要粗心大意

实际上，在解决以上分页搜索没有添加排序方式的问题之后，还存在着许多小问题。而这些小问题都反映了我的另一个不足：粗心大意。

正是这些小问题，导致线上环境总会出现个别搜索结果不一致的情况，导致这项工作被拖延很久。

课程模型是在线教育公司非常核心的数据模型，业务逻辑非常复杂，当然字段也非常多。在我入职时，该模型已经有120 个字段，并且有近 50 个字段可以进行检索。

在切换搜索方式时，我需要重新定义各种DO、DTO、Request等类型，还需新增多个类，并重新定义这些字段。在这个过程中，我必须确保不遗漏任何字段，也不能多加字段。当字段数量在20个以内时，这项工作出错的可能性非常低。然而，班课模型却有多达120个字段，因此出错的风险极大。当时我需要大量搬运这些字段，然而我只把这项工作看作是枯燥乏味的任务，未能深刻意识到出错的可能性极大，所以工作起来散漫随意，没有特别仔细校验重构前后代码的准确性。

墨菲定律：一件事可能出错时就一定会出错

墨菲定律是一种普遍被接受的观念，指出如果某件事情可能出错，那么它将以最不利的方式出错。这个定律起源于美国航天局的项目工程师爱德华·墨菲，在1950年代发现了这一规律。

墨菲定律还强调了人类的倾向，即将事情弄糟或让事情朝着最坏的方向发展。它提醒人们在计划和决策时要考虑可能出错的因素，并准备应对不利的情况。

墨菲定律实在是太准了，当你感觉某个事情可能会出错的时候，那它真的就会出错。而且我犯错不止一次，因为有120个字段，很多字段的命名非常相似，最终我遗漏了2个字段，拼写错误了一个字段，总共有三个字段出了问题。

不巧的是，这三个字段也参与检索。当用户在课程搜索页面选择这三个字段来进行检索时，因为字段的拼写错误和遗漏，这三个字段没有被包含在检索条件中，导致搜索结果出错……

导致这个问题的原因有很多，其中包括字段数量太多，我的工作不够细致，做事粗心大意，而且没有进行充分的测试……

为什么没有测试

小公司的测试人员相对较少，尤其是在面对课程管理后台的技术重构需求时，更加无法获取所需的测试资源！

组长对我说：“ 要人没有，要测试更没有！”

事情办砸了，十分遗憾

首先，从各个方面来看，切换搜索引擎这件事的复杂度和难度是可控的，而且目标也非常明确。作为入职后第一项任务，我应该准确快速地完成它，以留下一个良好印象。当然，领导也期望我能够做到这一点，然而事实与期望相去甚远。

虽然在线上环境没有出现问题，但在上线后，问题排查的时间却远远超出了预期，让领导对结果不太满意。

总的来说，从这件事中，我获得的最重要教训就是：对于可能出错的事情，要保持警惕。时刻用墨菲定律提醒自己，要仔细关注那些可能发生小概率错误的细节问题。

对于一些具有挑战性的工作，我们通常都非常重视，且在工作中也非常认真谨慎，往往不会出错。

然而，像大量搬运代码、搬运大量字段等这类乏味又枯燥的工作确实容易使人麻痹大意，因此我们必须提高警惕。要么我们远离这些乏味的工作，要么就要认真仔细地对待它们。

否则，如果对这些乏味工作粗心大意，墨菲定律一定会找上你，让你在线上翻车！

【新智元导读】 刚刚，英伟达发布了目前世界最强的AI芯片H200，性能较H100提升了60%到90%，还能和H100兼容。算力荒下，大科技公司们又要开始疯狂囤货了。

英伟达的节奏，越来越可怕了。

就在刚刚，老黄又一次在深夜炸场——发布目前世界最强的AI芯片H200！

较前任霸主H100，H200的性能直接提升了60%到90%。

不仅如此，这两款芯片还是互相兼容的。这意味着，使用H100训练/推理模型的企业，可以无缝更换成最新的H200。

全世界的AI公司都陷入算力荒，英伟达的GPU已经千金难求。英伟达此前也表示，两年一发布的架构节奏将转变为一年一发布。

就在英伟达宣布这一消息之际，AI公司们正为寻找更多H100而焦头烂额。

英伟达的高端芯片价值连城，已经成为贷款的抵押品。

谁拥有H100，是硅谷最引人注目的顶级八卦

至于H200系统，英伟达表示预计将于明年二季度上市。

同在明年，英伟达还会发布基于Blackwell架构的B100，并计划在2024年将H100的产量增加两倍，目标是生产200多万块H100。

而在发布会上，英伟达甚至全程没有提任何竞争对手，只是不断强调「英伟达的AI超级计算平台，能够更快地解决世界上一些最重要的挑战。」

随着生成式AI的大爆炸，需求只会更大，而且，这还没算上H200呢。赢麻了，老黄真的赢麻了！

141GB超大显存，性能直接翻倍！

H200，将为全球领先的AI计算平台增添动力。

它基于Hopper架构，配备英伟达H200 Tensor Core GPU和先进的显存，因此可以为生成式AI和高性能计算工作负载处理海量数据。

英伟达H200是首款采用HBM3e的GPU，拥有高达141GB的显存。

与A100相比，H200的容量几乎翻了一番，带宽也增加了2.4倍。与H100相比，H200的带宽则从3.35TB/s增加到了4.8TB/s。

英伟达大规模与高性能计算副总裁Ian Buck表示——

要利用生成式人工智能和高性能计算应用创造智能，必须使用大型、快速的GPU显存，来高速高效地处理海量数据。借助H200，业界领先的端到端人工智能超算平台的速度会变得更快，一些世界上最重要的挑战，都可以被解决。

Llama 2推理速度提升近100%

跟前代架构相比，Hopper架构已经实现了前所未有的性能飞跃，而H100持续的升级，和TensorRT-LLM强大的开源库，都在不断提高性能标准。

H200的发布，让性能飞跃又升了一级，直接让Llama2 70B模型的推理速度比H100提高近一倍！

H200基于与H100相同的Hopper架构。这就意味着，除了新的显存功能外，H200还具有与H100相同的功能，例如Transformer Engine，它可以加速基于Transformer架构的LLM和其他深度学习模型。

HGX H200采用英伟达NVLink和NVSwitch高速互连技术，8路HGX H200可提供超过32 Petaflops的FP8深度学习计算能力和1.1TB的超高显存带宽。

当用H200代替H100，与英伟达Grace CPU搭配使用时，就组成了性能更加强劲的GH200 Grace Hopper超级芯片——专为大型HPC和AI应用而设计的计算模块。

下面我们就来具体看看，相较于H100，H200的性能提升到底体现在哪些地方。

首先，H200的性能提升最主要体现在大模型的推理性能表现上。

如上所说，在处理Llama 2等大语言模型时，H200的推理速度比H100提高了接近1倍。

因为计算核心更新幅度不大，如果以训练175B大小的GPT-3为例，性能提升大概在10%左右。

显存带宽对于高性能计算（HPC）应用程序至关重要，因为它可以实现更快的数据传输，减少复杂任务的处理瓶颈。

对于模拟、科学研究和人工智能等显存密集型HPC应用，H200更高的显存带宽可确保高效地访问和操作数据，与CPU相比，获得结果的时间最多可加快110倍。

相较于H100，H200在处理高性能计算的应用程序上也有20%以上的提升。

而对于用户来说非常重要的推理能耗，H200相比H100直接腰斩。这样，H200能大幅降低用户的使用成本，继续让用户「买的越多，省的越多」！

上个月，外媒SemiAnalysis曾曝出一份英伟达未来几年的硬件路线图，包括万众瞩目的H200、B100和「X100」GPU。

而英伟达官方，也公布了官方的产品路线图，将使用同一构架设计三款芯片，在明年和后年会继续推出B100和X100。

B100，性能已经望不到头了

这次，英伟达更是在官方公告中宣布了全新的H200和B100，将过去数据中心芯片两年一更新的速率直接翻倍。

以推理1750亿参数的GPT-3为例，今年刚发布的H100是前代A100性能的11倍，明年即将上市的H200相对于H100则有超过60%的提升，而再之后的B100，性能更是望不到头。

至此，H100也成为了目前在位最短的「旗舰级」GPU。如果说H100现在就是科技行业的「黄金」，那么英伟达又成功制造了「铂金」和「钻石」。

H200加持，新一代AI超算中心大批来袭

云服务方面，除了英伟达自己投资的CoreWeave、Lambda和Vultr之外，亚马逊云科技、谷歌云、微软Azure和甲骨文云基础设施，都将成为首批部署基于H200实例的供应商。

此外，在新的H200加持之下，GH200超级芯片也将为全球各地的超级计算中心提供总计约200 Exaflops的AI算力，用以推动科学创新。

在SC23大会上，多家顶级超算中心纷纷宣布，即将使用GH200系统构建自己的超级计算机。

德国尤里希超级计算中心将在超算JUPITER中使用GH200超级芯片。

这台超级计算机将成为欧洲第一台超大规模超级计算机，是欧洲高性能计算联合项目（EuroHPC Joint Undertaking）的一部分。

Jupiter超级计算机基于Eviden的BullSequana XH3000，采用全液冷架构。

它总共拥有24000个英伟达GH200 Grace Hopper超级芯片，通过Quantum-2 Infiniband互联。

每个Grace CPU包含288个Neoverse内核， Jupiter的CPU就有近700万个ARM核心。

它能提供93 Exaflops的低精度AI算力和1 Exaflop的高精度（FP64）算力。这台超级计算机预计将于2024年安装完毕。

由筑波大学和东京大学共同成立的日本先进高性能计算联合中心，将在下一代超级计算机中采用英伟达GH200 Grace Hopper超级芯片构建。

作为世界最大超算中心之一的德克萨斯高级计算中心，也将采用英伟达的GH200构建超级计算机Vista。

伊利诺伊大学香槟分校的美国国家超级计算应用中心，将利用英伟达GH200超级芯片来构建他们的超算DeltaAI，把AI计算能力提高两倍。

此外，布里斯托大学将在英国政府的资助下，负责建造英国最强大的超级计算机Isambard-AI——将配备5000多颗英伟达GH200超级芯片，提供21 Exaflops的AI计算能力。

英伟达、AMD、英特尔：三巨头决战AI芯片

GPU竞赛，也进入了白热化。

面对H200，而老对手AMD的计划是，利用即将推出的大杀器——Instinct MI300X来提升显存性能。

MI300X将配备192GB的HBM3和5.2TB/s的显存带宽，这将使其在容量和带宽上远超H200。

而英特尔也摩拳擦掌，计划提升Gaudi AI芯片的HBM容量，并表示明年推出的第三代Gaudi AI芯片将从上一代的 96GB HBM2e增加到144GB。

英特尔Max系列目前的HBM2容量最高为128GB，英特尔计划在未来几代产品中，还要增加Max系列芯片的容量。

H200价格未知

所以，H200卖多少钱？英伟达暂时还未公布。要知道，一块H100的售价，在25000美元到40000美元之间。训练AI模型，至少需要数千块。此前，AI社区曾广为流传这张图片《我们需要多少个GPU》。

GPT-4大约是在10000-25000块A100上训练的；Meta需要大约21000块A100；Stability AI用了大概5000块A100；Falcon-40B的训练，用了384块A100。

根据马斯克的说法，GPT-5可能需要30000-50000块H100。摩根士丹利的说法是25000个GPU。

Sam Altman否认了在训练GPT-5，但却提过「OpenAI的GPU严重短缺，使用我们产品的人越少越好」。

我们能知道的是，等到明年第二季度H200上市，届时必将引发新的风暴。

参考资料：nvidianews.nvidia.com/news/nvidia…

方案一

double systemVersion = [UIDevice currentDevice].systemVersion.boolValue;



if (systemVersion >= 7.0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



if (systemVersion >= 10.0) {

    // >= iOS 10.0

} else {

    // < iOS 10.0

}

如果只是大致判断是哪个系统版本，上面的方法是可行的，如果具体到某个版本，如 10.0.1，那就会有偏差。我们知道 systemVersion 依旧是10.0。

方案二

NSString *systemVersion = [UIDevice currentDevice].systemVersion;

NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1" options:NSNumericSearch];



if (comparisonResult == NSOrderedAscending) {

    // < iOS 10.0.1

} else if (comparisonResult == NSOrderedSame) {

    // = iOS 10.0.1

} else if (comparisonResult == NSOrderedDescending) {

    // > iOS 10.0.1

}



// 或者



if (comparisonResult != NSOrderedAscending) {

    // >= iOS 10.0.1

} else {

    // < iOS 10.0.1

}

有篇博客提到这种方法不靠谱。比如系统版本是 10.1.1，而我们提供的版本是 8.2，会返回NSOrderedAscending，即认为 10.1.1 < 8.2 。

其实，用这样的比较方式 NSComparisonResult comparisonResult = [systemVersion compare:@"10.0.1"]，的确会出现这种情况，因为默认是每个字符逐个比较，即 1(0.1.1) < 8(.2)，结果可想而知。但我是用 NSNumericSearch 方式比较的，即数值的比较，不是字符比较，也不需要转化成NSValue(NSNumber) 再去比较。

方案三

if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}



// 或者



if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber_iOS_7_0) {

    // >= iOS 7.0

} else {

    // < iOS 7.0

}

这些宏定义是 Apple 预先定义好的，如下：

#if TARGET_OS_IPHONE

...

#define NSFoundationVersionNumber_iOS_9_4 1280.25

#define NSFoundationVersionNumber_iOS_9_x_Max 1299

#endif

细心的童靴可能已经发现问题了。Apple 没有提供 iOS 10 以后的宏？，我们要判断iOS10.0以后的版本该怎么做呢？
有篇博客中提到，iOS10.0以后版本号提供了，并且逐次降低了，并提供了依据。

#if TARGET_OS_MAC

#define NSFoundationVersionNumber10_1_1	425.00

#define NSFoundationVersionNumber10_1_2	425.00

#define NSFoundationVersionNumber10_1_3	425.00

#define NSFoundationVersionNumber10_1_4	425.00

...

#endif

我想这位童鞋可能没仔细看， 这两组宏是分别针对iPhone和macOS的，不能混为一谈的。

所以也只能像下面的方式来大致判断iOS 10.0， 但之前的iOS版本是可以准确判断的。

if (NSFoundationVersionNumber > floor(NSFoundationVersionNumber_iOS_9_x_Max)) {

    // > iOS 10.0

} else {

    // <= iOS 10.0

}

方案四

在iOS8.0中，Apple也提供了NSProcessInfo 这个类来检测版本问题。

@property (readonly) NSOperatingSystemVersion operatingSystemVersion NS_AVAILABLE(10_10, 8_0);

- (BOOL) isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion)version NS_AVAILABLE(10_10, 8_0);

所以这样检测：

if ([[NSProcessInfo processInfo] isOperatingSystemAtLeastVersion:(NSOperatingSystemVersion){.majorVersion = 8, .minorVersion = 3, .patchVersion = 0}]) {

     // >= iOS 8.3

} else {

     // < iOS 8.3

}

用来判断iOS 10.0以上的各个版本也是没有问题的，唯一的缺点就是不能准确版本是哪个版本，当然这种情况很少。如果是这种情况，可以通过字符串的比较判断。

方案五

通过判断某种特定的类有没有被定义，或者类能不能响应哪个特定版本才有的方法。
比如，UIAlertController 是在iOS 8.0才被引进来的一个类，我们这个依据来判断版本

if (NSClassFromString(@"UIAlertController")) {

    // >= iOS 8.0

} else {

    // < iOS 8.0

}

说到这里，就顺便提一下在编译期间如何进行版本控制，依然用UIAlertController 来说明。

NS_CLASS_AVAILABLE_IOS(8_0) @interface UIAlertController : UIViewController

NS_CLASS_AVAILABLE_IOS(8_0) 这个宏说明，UIAlertController 是在iOS8.0才被引进来的API，那如果我们在iOS7.0上使用，应用程序就会挂掉，那么如何在iOS8.0及以后的版本使用UIAlertController ，而在iOS8.0以前的版本中仍然使用UIAlertView 呢？

这里我们会介绍一下在#import <AvailabilityInternal.h> 中的两个宏定义：

*__IPHONE_OS_VERSION_MIN_REQUIRED

*__IPHONE_OS_VERSION_MAX_ALLOWED

从字面意思就可以直到，__IPHONE_OS_VERSION_MIN_REQUIRED 表示iPhone支持最低的版本系统，__IPHONE_OS_VERSION_MAX_ALLOWED 表示iPhone允许最高的系统版本。

__IPHONE_OS_VERSION_MAX_ALLOWED 的取值来自iOS SDK的版本，比如我现在使用的是Xcode Version 8.2.1（8C1002），SDK版本是iOS 10.2，怎么看Xcode里SDK的iOS版本呢？

进入PROJECT，选择Build Setting，在Architectures中的Base SDK中可以查看当前的iOS SDK版本。

打印这个宏，可以看到它一直输出100200。

__IPHONE_OS_VERSION_MIN_REQUIRED 的取值来自项目TARGETS的Deployment Target，即APP愿意支持的最低版本。如果我们修改它为8.2，打印这个宏，会发现输出80200，默认为10.2。

通常，__IPHONE_OS_VERSION_MAX_ALLOWED 可以代表当前的SDK的版本，用来判断当前版本是否开始支持或具有某些功能。而__IPHONE_OS_VERSION_MIN_REQUIRED 则是当前SDK支持的最低版本，用来判断当前版本是否仍然支持或具有某些功能。

回到UIAlertController 使用的问题，我们就可以使用这些宏，添加版本检测判断，从而使我们的代码更健壮。

 - (void)showAlertView {

#if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_9_0

    UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Title" message:@"message" delegate:nil cancelButtonTitle:@"Cancel" otherButtonTitles:@"OK", nil];

    [alertView show];

#else

    if (NSFoundationVersionNumber >= NSFoundationVersionNumber_iOS_8_0) {

        UIAlertController *alertViewController = [UIAlertController alertControllerWithTitle:@"Title" message:@"message" preferredStyle:UIAlertControllerStyleAlert];



        UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:nil];

        UIAlertAction *otherAction = [UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:nil];



        [alertViewController addAction:cancelAction];

        [alertViewController addAction:otherAction];



        [self presentViewController:alertViewController animated:YES completion:NULL];

    }

#endif

}

方案六

iOS 11.0 以后，Apple加入了新的API，以后我们就可以像在Swift中的那样，很方便的判断系统版本了。

if (@available(iOS 11.0, *)) {

	// iOS 11.0 及以后的版本

} else {

	// iOS 11.0 之前

}

参考链接

• http://www.360doc.com/content/14/…


• http://www.tuicool.com/articles/3I…


• segmentfault.com/a/119000000…


• http://www.tuicool.com/articles/Nr…

一. 前言。

蓝牙功能在我们日常软件中的使用率还是蛮高的----譬如各类共享单车/电单车。正因此，我们开发中接触蓝牙功能也是日渐增长。对于很多从未开发过蓝牙功能的童鞋来说，当PM小姐姐扔过来一个蓝牙协议要你接入时，简直一头雾水（我是谁？我在哪？）。只能一翻度娘和AI，可是网上文章大多水准参差不齐，技术五花八门，没法真正地让你从无到有掌握蓝牙功能/协议对接。

二. 说明。

本文就基于uni-app框架结合微信和支付宝小程序为例，来讲述蓝牙功能在各类型小程序中的整体开发流程和如何“优雅”高效的封装蓝牙功能模块。本文使用到的主要技术栈和环境有：

• uni-app


• JavaScript


• AES加解密


• 微信小程序


• 支付宝小程序

三. 蓝牙流程图。

正所谓“知己知彼，百战不殆”，所以在讲述蓝牙模块如何在小程序中开发和封装之前，我们先要了解蓝牙功能模块是如何在小程序中“走向”的，各API是如何交互通讯的。为了让大家看得清楚，学的明白----这里简明扼要地梳理了一份蓝牙核心API流程图（去除了非必要的逻辑走向，只展示了实际开发中最重要的步骤和交互）。

• uni-app： 蓝牙API


• 微信小程序：蓝牙API


• 支付宝小程序：蓝牙API


• 核心API流程图（注：每家厂商的小程序API大同小异，uni-app的基本通用，具体明细详见各厂商开发文档）：

四. 蓝牙协议。

了解完开发所需的API后，就需要根据实际开发场景中所对接的硬件和其厂家提供的蓝牙对接协议来结合上述的API来编写代码了。每家厂商的蓝牙协议是不一样的，不过“万变不离其宗”。只要知道其中的规则，真正看懂一家，那换其他家的也是可以看懂的。本文以下述协议（蓝牙寻车+蓝牙开锁）为例解释下。

1. 寻车：

• 协议内容：

• 解读：

根据上述图文的描述，我们可以知道想要开启蓝牙锁，那么必须先通过寻车蓝牙指令（7B5B01610060 或 7B5B01610160）写入，然后根据蓝牙响应的信息功能体和错误码判断响应是否正确，如正确，那么就拿到此时的随机数，后根据协议规定对该随机数做相应的处理，最后将处理后得到的结果用于组装开锁的蓝牙写入指令。

• 案例代码：

2. 开锁：

• 协议内容：

• 解读：

根据上述图文的描述，我们可以知道开锁的写入指令是需要自己组装的，组装规则为：7B5B（数据头） 1B（信息体长度） 62（信息功能） 00（秘钥索引）018106053735（补1位0的电话号码）4B大端的时间戳 寻车拿到的随机码补8位0后经AES加密组合得到的16B数据 00（校验码）；所以开锁写入的数据就是这种（案例：7B5B1B6200018106053735XXXXXXXXXXXXXXXXXXXX）。响应的话，也是根据信息功能体和错误码来判断开锁失败（9201）还是成功（9200）。

• 案例代码：

五.代码编写。

这里为了提高蓝牙模块的代码耦合度，我们会把业务层和蓝牙模块层分离出来----也就是会把蓝牙整体流程交互封装成一个蓝牙模块js，然后根据业务形态，在各个业务层面上通过传参的形式来区分每个组件的蓝牙功能。

1. 业务层：

• 核心代码：

//引入封装好的蓝牙功能JS模块核心方法函数

import { operateBluetoothYws } from '@/utils/bluetoothYws.js';



//调用蓝牙功能

blueTooth() {

    //初始化蓝牙模块,所有的蓝牙API都需要在此步成功后才能调用

    uni.openBluetoothAdapter({

        success(res) {

            console.log('初始化蓝牙成功res', res);

            let mac = 'FF8956DEDA29';

            let key = 'oYQMt8LFavXZR6sB';

            operateBluetoothYws('open', mac, key, flag => {

                if (flag) {

                        console.log('flag存在回调函数--蓝牙成功，可以执行后续步骤了', flag);

                } else {

                        console.log('flag不存在回调函数--蓝牙成功，可以执行后续步骤了', flag);

                }

            })

        },

        fail(err) {

                console.log('初始化蓝牙失败err', err);

        }

    })

},

• 解读:

这里是我们具体业务层需要的写法，一开始就是引入我们封装好的蓝牙JS模块核心方法函数（operateBluetoothYws），然后启用uni.openBluetoothAdapter这个蓝牙功能启动前提，成功后在其success内执行operateBluetoothYws方法，此时的参数根据实际开发业务和相对应的蓝牙协议而定（这里以指令参数、设备编号和AES加密秘钥为例），实际中每个mac和key是数据库一一匹配的，我们按后端童鞋提供的接口获取即可（这里为了直观直接写死）。

2. 蓝牙模块层：

• 核心代码：

let CryptoJS = require('./crypto-js.min.js'); //引入AES加密

let callBack = null; //回调函数，用于与业务层交互

let curOrder; //指令（开锁还是关锁后取锁的状态）

let curMac; //当前扫码的车辆编码对应的设备mac

let curKey; //当前扫码的车辆编码对应的秘钥secret（用于AES加密）

let curDeviceId; //当前扫码的车辆编码对应的设备的 id

let curServiceId; //蓝牙服务 uuid，需要使用 getBLEDeviceServices 获取

let curCharacteristicRead; //当前设备读的uuid值

let curCharacteristicWrite; //当前设备写的uuid值





//蓝牙调用核心方法（order: 指令；mac：车辆编码；key：秘钥secret；cb：回调）

function operateBluetoothYws(order,mac, key, cb) {

    curOrder = order;

    curMac = mac;

    curKey = key;

    callBack = cb

    searchBluetooth();

}



//第一步（uni.startBluetoothDevicesDiscovery(OBJECT)，开始搜寻附近的蓝牙外围设备。）

function searchBluetooth() {

    uni.startBluetoothDevicesDiscovery({

        services: ['00000001-0000-1000-8000-00805F9B34FB', '00000002-0000-1000-8000-00805F9B34FB'],

        success(res) {

            console.log('第一步蓝牙startBluetoothDevicesDiscovery搜索成功res', res)

            watchBluetoothFound();

        },

        fail(err) {

            console.log('第一步蓝牙startBluetoothDevicesDiscovery搜索失败err', err)

            callBack && callBack(false)

        }

    })

}



//第二步（uni.onBluetoothDeviceFound(CALLBACK)，监听寻找到新设备的事件。）

function watchBluetoothFound() {

    uni.onBluetoothDeviceFound(function(res) {

        curDeviceId = res.devices.filter(i => i.localName.includes(curMac))[0].deviceId;

        stopSearchBluetooth()

        connectBluetooth()

    })

}



//第三步（uni.createBLEConnection(OBJECT)，连接低功耗蓝牙设备。）

function connectBluetooth() {

    if (curDeviceId.length > 0) {

        // #ifdef MP-WEIXIN

        uni.createBLEConnection({

            deviceId: curDeviceId,

            timeout: 5000,

            success: (res) => {

                console.log('第三步通过deviceId连接蓝牙设备成功res', res);

                getBluetoothServers()

            },

            fail: (err) => {

                console.log('第三步通过deviceId连接蓝牙设备失败err', err);

                callBack && callBack(false)

            }

        });

        // #endif

        // #ifdef MP-ALIPAY

        my.connectBLEDevice({

            deviceId: curDeviceId,

            timeout: 5000,

            success: (res) => {

                console.log('第三步通过deviceId连接蓝牙设备成功res', res);

                getBluetoothServers()

            },

            fail: (err) => {

                console.log('第三步通过deviceId连接蓝牙设备失败err', err);

                callBack && callBack(false)

            }

        });

        // #endif

    }

}



//第四步（uni.stopBluetoothDevicesDiscovery(OBJECT)，停止搜寻附近的蓝牙外围设备。）

function stopSearchBluetooth() {

    uni.stopBluetoothDevicesDiscovery({

        success: (res) => {

            console.log('第四步停止搜寻附近的蓝牙外围设备成功res', res);

        },

        fail: (err) => {

            console.log('第四步停止搜寻附近的蓝牙外围设备失败err', err);

        }

    })

}



//第五步（uni.getBLEDeviceServices(OBJECT)，获取蓝牙设备所有服务(service)。）

function getBluetoothServers() {

    uni.getBLEDeviceServices({

        deviceId: curDeviceId,

        success(res) {

            console.log('第五步获取蓝牙设备所有服务成功res', res);

            //这里取res.services中的哪个，这是硬件产商配置好的，不同产商不同，具体看对接协议

            if (res.services && res.services.length > 1) {

                    curServiceId = res.services[1].uuid

                    getBluetoothCharacteristics()

            }

        },

        fail(err) {

            console.log('第五步获取蓝牙设备所有服务失败err', err);

            callBack && callBack(false)

        }

    })

}



//第六步（uni.getBLEDeviceCharacteristics(OBJECT)，获取蓝牙设备某个服务中所有特征值(characteristic)。）

function getBluetoothCharacteristics() {

    // #ifdef MP-WEIXIN

    uni.getBLEDeviceCharacteristics({

        deviceId: curDeviceId,

        serviceId: curServiceId,

        success: (res) => {

            console.log('第六步获取蓝牙设备某个服务中所有特征值成功res', res);

            curCharacteristicWrite = res.characteristics.filter(item => item && item.uuid.includes('0002'))[

                    0].uuid

            curCharacteristicRead = res.characteristics.filter(item => item && item.uuid.includes('0003'))[

                    0].uuid

            notifyBluetoothCharacteristicValueChange()

        },

        fail: (err) => {

            console.log('第六步获取蓝牙设备某个服务中所有特征值失败err', err);

            callBack && callBack(false)

        }

    });

    // #endif

    // #ifdef MP-ALIPAY

    my.getBLEDeviceCharacteristics({

        deviceId: curDeviceId,

        serviceId: curServiceId,

        success: (res) => {

            console.log('第六步获取蓝牙设备某个服务中所有特征值成功res', res);

            curCharacteristicWrite = res.characteristics.filter(item => item && item.characteristicId.includes('0002'))[

                    0].characteristicId

            curCharacteristicRead = res.characteristics.filter(item => item && item.characteristicId.includes('0003'))[

                    0].characteristicId

            notifyBluetoothCharacteristicValueChange()

        },

        fail: (err) => {

            console.log('第六步获取蓝牙设备某个服务中所有特征值失败err', err);

            callBack && callBack(false)

        }

    });

    // #endif

}



//第七步（uni.notifyBLECharacteristicValueChange(OBJECT)，启用低功耗蓝牙设备特征值变化时的 notify 功能，订阅特征值。）

function notifyBluetoothCharacteristicValueChange() {

    uni.notifyBLECharacteristicValueChange({

        deviceId: curDeviceId,

        serviceId: curServiceId,

        characteristicId: curCharacteristicRead,

        state: true,

        success(res) {

            console.log('第七步启用低功耗蓝牙设备特征值变化时的 notify 功能，订阅特征值成功res', res);

            if(curOrder == 'open'){

                //寻车指令

                getRandomCode();

            }else if(curOrder == 'close'){

                //查看锁状态指令

                getLockStatus();

            }else{



            }		

            //第八步（监听）（uni.onBLECharacteristicValueChange(CALLBACK)，监听低功耗蓝牙设备的特征值变化事件。）,含下发指令后的上行回应接受

            //这里会一直监听设备上行，所以日志等需清除

            uni.onBLECharacteristicValueChange((characteristic) => {

                // #ifdef MP-WEIXIN

                //完整的蓝牙回应数据

                let ciphertext = ab2hex(characteristic.value);			

                //蓝牙回应数据的信息功能体和错误码

                let curFeature = ab2hex(characteristic.value).slice(6, 10);

                //蓝牙回应数据的错误码

                let errCode = ab2hex(characteristic.value).slice(8, 10);

                // #endif



                // #ifdef MP-ALIPAY

                //完整的蓝牙回应数据

                let ciphertext = characteristic.value;			

                //蓝牙回应数据的信息功能体和错误码

                let curFeature = characteristic.value.slice(6, 10);

                //蓝牙回应数据的错误码

                let errCode = characteristic.value.slice(8, 10);

                // #endif

                if (curFeature.startsWith('91')) { //寻车响应，拿到随机码

                    //用于给开锁的随机码

                    getUnlockData(ciphertext)

                } else if (curFeature.startsWith('9200')) { //开锁响应(成功)

                    callBack && callBack(true)

                } else if (curFeature.startsWith('98')) { //关锁后APP主动读取后的响应，查看是否已关锁

                    if (curFeature == '9801') { //关锁成功

                        callBack && callBack(true)

                    } else { //关锁失败

                        callBack && callBack(false)

                    }

                } else {



                }

            })

        },

        fail(err) {

            console.log('第七步启用低功耗蓝牙设备特征值变化时的 notify 功能，订阅特征值失败err', err);

            callBack && callBack(false)

        }

    })

}



// ArrayBuffer转16进度字符串示例

function ab2hex(buffer) {

  const hexArr = Array.prototype.map.call(

    new Uint8Array(buffer),

    function (bit) {

      return ('00' + bit.toString(16)).slice(-2)

    }

  )

  return hexArr.join('')

}



//寻车指令，用于拿到开锁所需的随机码

function getRandomCode() {

    let str = '7B5B01610060';

    writeBLE(str)

}



//开锁指令，获取到开锁所需的数据

function getUnlockData(ciphertext) {

    if (ciphertext.length > 16) { //确保寻车后蓝牙响应内容有用于开锁的随机码

        //开锁头（固定值）

        let headData = '7B5B1B6200';

        //用户手机号

        let userPhone = '018106053735';

        //4B大端秒级时间戳

        let timestamp = convertLettersToUpperCase(decimalToHex(getSecondsTimestamp()));

        //随机码 + 8个‘0’

        let randomVal = convertToLower(ciphertext.slice(16, 24)) + '00000000';

        //AES加密后的前32位密文

        let aesResult = aesEncrypt(randomVal,curKey).slice(0,32)

        //校验码

        let checkCode = '00';

        //最后用于发指令的内容

        let result = headData + userPhone + timestamp + aesResult + checkCode;

        writeBLE(result)

    } else {

        getRandomCode();

    }

}



//查看锁状态指令，用于验证用户手工关锁后查询是否真的已关锁

function getLockStatus() {

    let str = '7B5B006868';

    writeBLE(str)

}



//AES的ECB方式加密，以hex格式(转大写)输出;参数一：明文数据，参数二：秘钥

function aesEncrypt(encryptString, key) {

    let aeskey = CryptoJS.enc.Utf8.parse(key);

    let aesData = CryptoJS.enc.Utf8.parse(encryptString);

    let encrypted = CryptoJS.AES.encrypt(aesData, aeskey, {

        mode: CryptoJS.mode.ECB,

        padding: CryptoJS.pad.Pkcs7

    });

    //将base64格式转为hex格式并转换成大写

    let password = encrypted.ciphertext.toString().toUpperCase()

    return password;

}



//处理写入数据

function writeBLE(str) {

    //如果大于20个字节则分包发送

    if (str.length > 20) {

        let curArr = splitString(str,20);

        // #ifdef MP-WEIXIN

        curArr.map(i => writeBLECharacter(hexStringToArrayBuffer(i)))

        // #endif



        // #ifdef MP-ALIPAY

        curArr.map(i => writeBLECharacter(i))

        // #endif	

    } else {

        // #ifdef MP-WEIXIN

        writeBLECharacter(hexStringToArrayBuffer(str));

        // #endif



        // #ifdef MP-ALIPAY

        writeBLECharacter(str);

        // #endif

    }

}



//第八步（写入）（uni.writeBLECharacteristicValue(OBJECT)，向低功耗蓝牙设备特征值中写入二进制数据。）

function writeBLECharacter(bufferValue){

    uni.writeBLECharacteristicValue({

        deviceId: curDeviceId,

        serviceId: curServiceId,

        characteristicId: curCharacteristicWrite,

        value: bufferValue,

        success(res) {

            console.log('第八步（写入）向低功耗蓝牙设备特征值中写入二进制数据成功res', res);

        },

        fail(err) {

            console.log('第八步（写入）向低功耗蓝牙设备特征值中写入二进制数据失败err', err);

            callBack && callBack(false)

        }

    })

}



//将字符串以每length位分割为数组

function splitString(str, length) {

  var result = [];

  var index = 0;

  while (index < str.length) {

    result.push(str.substring(index, index + length));

    index += length;

  }

  return result;

}



//字符转ArrayBuffer

function hexStringToArrayBuffer(str) {

    // 将16进制转化为ArrayBuffer

    return new Uint8Array(str.match(/[\da-f]{2}/gi).map(function(h) {

        return parseInt(h, 16)

    })).buffer

}



//对字符串中的英文大写转小写

function convertToLower(str) {

    var result = '';

    for (var i = 0; i < str.length; i++) {

        if (/[a-zA-Z]/.test(str[i])) {

            result += str[i].toLowerCase();

        } else {

            result += str[i];

        }

    }

    return result;

}



//对字符串中的英文小写转大写

function convertLettersToUpperCase(str) {

    var result = str.toUpperCase(); // 将字符串中的字母转换为大写

    return result;

}



//获取秒级时间戳（十进制）

function getSecondsTimestamp() {

    var timestamp = Math.floor(Date.now() / 1000); // 获取当前时间戳（单位为秒）

    return timestamp;

}



//将十进制时间戳转成十六进制

function decimalToHex(timestamp) {

    var hex = timestamp.toString(16); // 将十进制时间戳转换为十六进制字符串

    return hex;

}





//抛出蓝牙核心方法

module.exports = {

    operateBluetoothYws

};

• 解读:

这里的步骤和上面流程图中的步骤走向是一样的，不过里面的详情，笔者还是想每一步都拆开来对着实际案例讲述为好，详见下文（这里主要是为了照顾小白，大佬勿怪）。

六. 蓝牙模块层各步骤详解。

1. 蓝牙功能调用核心方法的定义和导出（operateBluetoothYws）

operateBluetoothYws 这里没啥好特别的，就是将业务层传进来的参数做个中转处理，为后续步骤的api所调用，详见上文代码及其注释。

2. 第一步（uni.startBluetoothDevicesDiscovery(OBJECT)）

uni.startBluetoothDevicesDiscovery 这里主要注意的是services这个参数，这个参数会由硬件厂家提供，一般在其提供的蓝牙协议文档中会标注，作用是要搜索的蓝牙设备主 service 的 uuid 列表。某些蓝牙设备会广播自己的主 service 的 uuid。如果设置此参数，则只搜索广播包有对应 uuid 的主服务的蓝牙设备。建议主要通过该参数过滤掉周边不需要处理的其他蓝牙设备。

3. 第二步（uni.onBluetoothDeviceFound(CALLBACK)）

uni.onBluetoothDeviceFound 这一步用来确定目标设备id，即后续步骤所需的参数deviceId。 这里主要注意的是其回调函数的devices结果，我们要根据厂家或其提供的蓝牙对接协议规定和我们业务层传进来的mac来匹配筛选出目标设备（因为这里会监听到第一步同样的uuid的每一台设备）（这里我就一台设备测试，所以回调函数的devices结果数组中内容就一个；然后之所以用localName.includes(curMac) 来匹配目标设备，这是根据厂商协议文档来做的，每家厂商和每种设备不一样，这里要按实际情况处理，不过万变不离其宗）。

4. 第三步（uni.createBLEConnection(OBJECT)）

uni.createBLEConnection 这里没啥特别的，主要就是用到第二步中得到的deviceId去连接低功耗蓝牙目标设备。需要注意的是这里支付宝小程序的API不一致，为my.connectBLEDevice。

5. 第四步（uni.stopBluetoothDevicesDiscovery(OBJECT)）

uni.stopBluetoothDevicesDiscovery 这一步主要是为了节省电量和资源，在第三步连接目标设备成功后给停止搜寻附近的蓝牙外围设备。

6. 第五步（uni.getBLEDeviceServices(OBJECT)）

uni.getBLEDeviceServices 这里通过第二步中得到的deviceId用来获取蓝牙目标设备的所有服务并确定后续步骤所需用的蓝牙服务uuid（serviceId）。这里取res.services中的哪个，这是硬件厂商定好的，不同厂商不同，具体看对接协议（案例中的是固定放在第2个，所以是通过curServiceId = res.services[1].uuid得到）。

7. 第六步（uni.getBLEDeviceCharacteristics(OBJECT)）

uni.getBLEDeviceCharacteristics 这里通过第二步获取的目标设备IddeviceId和第五步获取的蓝牙服务IdserviceId来得到目标设备的写的uuid和读的uuid。这里取characteristics的哪一个也是要根据厂商和其提供的蓝牙协议文档来决定的（案例以笔者这的协议文档为主，所以是这样获取的：curCharacteristicWrite = res.characteristics.filter(item => item && item.uuid.includes('0002'))[0].uuid 和 curCharacteristicRead = res.characteristics.filter(item => item && item.uuid.includes('0003'))[0].uuid）。需要注意的是这里支付宝小程序的API不一致，为my.getBLEDeviceCharacteristics，其res返回值也不一样，curCharacteristicWrite = res.characteristics.filter(item => item && item.characteristicId.includes('0002'))[0].characteristicId 和 curCharacteristicRead = res.characteristics.filter(item => item && item.characteristicId.includes('0003'))[0].characteristicId。

8. 第七步（uni.notifyBLECharacteristicValueChange(OBJECT)）

uni.notifyBLECharacteristicValueChange 这里就是开启低功耗蓝牙设备特征值变化时的 notify 功能，订阅特征值。可以在其的success内执行一些写入操作和执行uni.onBLECharacteristicValueChange(CALLBACK)来监听低功耗蓝牙设备的特征值变化事件了。

9. 第八步（写入）（uni.writeBLECharacteristicValue(OBJECT)）

uni.writeBLECharacteristicValue 这里特别要注意的是参数value必须为二进制值（这里需用注意的是支付宝小程序的参数value可以不为二进制值，可直接传入，详见支付宝小程序开发文档）；并且单次写入不得超过20字节，超过了需分段写入。

10. 第八步（监听）（uni.onBLECharacteristicValueChange(CALLBACK)）

uni.onBLECharacteristicValueChange 这里需根据实际开发的业务场景对CALLBACK 返回参数转16进度字符串后自行处理（支付宝小程序如果写入时未转换，那么这里读取时也不需要转换）（本文以寻车--开锁--检测锁状态为例）。

七. 总结。

以上就是本文的所有内容，主要分为2部分----业务层和蓝牙模块层（封装）。业务层只需要关注目标设备和其对应的密钥（不同厂家和设备不同）；蓝牙模块层主要是按蓝牙各API拿到以下四要素并按流程图一步步执行即可。

1. 蓝牙设备Id：deviceId


2. 蓝牙服务uuid：serviceId


3. 蓝牙写操作的uuid


4. 蓝牙读操作的uuid

至此，如何在小程序中优雅地封装蓝牙模块并高效使用就已经完结了，当然本文只是以最简而易学的案例来讲述蓝牙模块开发，大多只处理了success的后续，至于fail后续可以根据大家实际业务处理。相信看到这，你已经对小程序开发蓝牙功能，对接各种蓝牙协议已经有一定的认识了，再也不虚PM小姐姐的蓝牙需求了。完结撒花~ 码文不易，还请各位大佬三连鼓励（如发现错别之处，还请联系笔者修正）。

流量就是钱，这是一个很原始的认知。但最开始我并不清楚流量和钱之间是如何相互转化的。

微创业，认知很低

大学时期，不管是出于积累项目经验、还是折腾新技术的需要，我有做过一个相对完整的项目。

没记错的话，应该是在20年10月份启动的。当时在宿舍里买了一台激光打印机，做起了点小买卖。所以就发现如果我手动给同学处理订单会非常麻烦。他们把文件通过qq发给我，我这边打开，排版，确认格式没有问题之后算一个价格，然后打印。

所以根据痛点，我打算开发一个线上自助下单，商户自动打印的一整套系统。

百折不挠，项目终于上线

21年年中克服各种困难终于实现整套系统，提供了小程序端，商户客户端，web端。

用户在手机或网页上上传文件后会自动转换为pdf，还提供了在线预览，避免因为格式与用户本地不同的纠纷。可以自由调节单双面、打印范围、打印分数、色彩等参数。实时算出价格，自助下单。下单后服务器会通知商户客户端拉取新任务，拉取成功后将文件丢入打印队列中。打印完成后商户客户端发送信息，并由服务器转发，告知用户取件。

大三下学期，宿舍里通过线上平台，在期末考试最忙那段期间经过了“订单高峰”的考验，成交金额上千块钱。看着我商户端里面一个个跳动的文件，就像流入口袋里的💰，开心。

商业化的很失败

没想到，我自己就是我最大的客户。

期末考完，其实想拉上我的同学大干一场，让校里校外的所有的商户，都用上我们的软件，多好的东西啊。对于盈利模式的概念非常模糊，同时也有很强的竞品。我的同学并不看好我。

我对商业化的理解也源自美团模式，美团是外卖的流量入口，所以对商户抽佣很高。滴滴是打车的流量入口，对司机的抽佣也很高。所以我认为，假设我未来成为了自助打印的流量入口，那应该也可以试试抽佣模式。

而且就算我不能为商户引流，也能解放他们的双手。

当时的我，一个人做技术，做UI，还要做商业计划，去地推，真的搞得我精疲力尽。反正后面觉得短期内变现无望，就去腾讯实习了。

其实也推广了2个商户，但是他们因为各种原因不愿意用。一个是出于隐私合规风险的考虑，一个是订单量少，不需要。

所以基本这个自助打印只能框死在高校。大学生打印的文件私密性很低，但是单价低，量多，有自助打印的需求。还有一部分自助打印的场景是在行政办事大厅，这种估计没点门门道道是开不进去的。

看不懂的竞品玩法

商户通过我的平台走，我这边并不无本万利。

因为开通了微信支付、支付宝支付，做过的小伙伴应该都知道办这些手续也会花一些钱，公司还要每年花钱养。还有需要给用户的文档成转换成pdf，提供在线预览，这很消耗算力和带宽，如果用户的成交单价非常低，哪怕抽佣5%都是亏的。比如用户打印了100份1页的内容，和打印了1份100页的内容，对我来说成本差别很大，前者很低，后者很高。

当时学校里已经有一部分商户用上自助打印了。一共有3个竞品。

竞品A：不抽佣，但是每笔订单对用户收取固定的服务费，界面简陋，有广告。

竞品B：不抽佣，不收用户的服务费，界面清爽无广告。

竞品C：彻彻底底走无人模式，店铺内基本没有老板，店铺是自营或加盟的。

前期缺乏市场调研，后期缺乏商业认知

当时我在没有摸清自己商业模式，市场调研也没怎么做好的情况下。一心想的就是先把东西做出来再说，卖不成自己还能学到技术。毕竟技术这个玩意不在项目里历练，永远都是纸上谈兵。所以对于商业化的设想就是搞不成就不搞了。

我当时的想法就是要“轻”运营，就是最好我的利润是稳定的，不会亏损的。商户如果要用就得每笔订单都给我一笔钱。

后面为了补齐和竞品的功能差距，也耗费了大量心力。让我把项目从一个大学课程设计，变成了一个有商业化潜力的产品。

竞品玩法的底层逻辑

商业化的时候，就发现这个市场还是蛮卷的，不可能直接和商户收钱。竞品B不仅免费，还想着帮商户创造额外收入，做“增益”。那我确实是没有精力去对抗的。

我当时也没搞懂自己的定位，我究竟是tob还是toc。当时想着我精心设计的界面，怎么可以被广告侵蚀？那可是我的心血。所以一心想把产品体验做的比竞品好，就会有人用。但这个定位也很模糊，因为如果商户不用你的，用户怎么可能用你的下单呢。

其实应该to rmb。面向利润开发。美，是奢侈品，那是属于我内心的一种追求，但他很难具有说服力让商户使用。在国内的各种互联网产品，不盈利的产品最后都是越来越粗糙，越来越丑的，都要降本增效。而rmb是必需品，如果不能为各方创造价值，那就没有竞争力。

所以后续分析了一下各家的玩法：

竞品A：传统商业模式，依靠用户强制付费和广告，市占率一般，和第一差了10倍数量级。

竞品B：烧钱模式，免费给商户用，免费给用户用，自己想办法别的渠道做增益，还要补贴商户。市占率第一。先圈地，再养鱼，变现的事之后再说。

竞品C：不单单做打印软件，卖的是项目。一整套自助打印店的解决方案，不知道店铺能不能赚钱，但是可以先赚加盟商的钱。这个对商业运作的要求会很高，我一时半会做不了。

大佬指点了一下我

他说，你看现在什么自助贩卖机，其实就是一个流量入口。至于别的盈利不盈利再说，但是流量是值钱的。

我最近去查阿拉丁指数，了解到了买量和卖量的观念，重新认识了流量，因为知道价格了。

买量和卖量是什么？

买量说的就是你做了一个app，花钱让别人给你引流。

卖量就是你有一个日活很高的平台，可以为别人引流。

买量和卖量如何结算？

一般分为cpc和cpa两种计价方式。前者是只要用户点击了我的引流广告，广告主就得掏钱。后者是用户可能还需要注册并激活账号，完成一系列操作才掏钱。

一般价格在0.1-0.3元，每次引流。

后面我查了一下竞品B在卖量，每天可以提供10-30w的uv，单次引流报价0.1元。也就是理想情况下，每天可以有1-3w的广告费收入。

侧面说明了竞品B的市占率啊，在这个细分市场做到这个DAU……

关于流量，逆向思维的建立

流量是实现商业利益的工具。

工具类应用通过为别人引流将流量变现，内容类应用通过电商将流量变现的更贵。

依靠流量赚钱有两种姿势，主动迎合需求，和培养需求。前者就是你可以做一些大家必须要用的东西，来获得流量。比如自助打印小程序，只要商户接入了，那么他的所有顾客都会为这个小程序贡献流量。比如地铁乘车码，所有坐地铁的人都会用到，比如广州地铁就在卖量，每天有几百万的日活。

培养需求就是做自己看好的东西，但是当下不明朗，尝试发掘用户潜在的需求。

流量，如果不能利用好，那就是无效流量。所以正确的姿势是，发掘目标人群 -> 设计变现方案 -> 针对性的开发他们喜欢的内容或工具 -> 完成变现。而不是 自己发现有个东西不错 -> 开发出来 -> 测试一下市场反应 -> 期盼突然爆红，躺着收钱。

研究报告也蛮有意思，主打的就是一个研究如何将用户口袋里的钱转移到自己口袋里。做什么产品和个人喜好无关，和有没有市场前景相关。

互联网是基于实体的

互联网并不和实体脱钩，大部分平台依赖广告收入，但广告基本都是实体企业来掏钱。还有电商也是，消费不好，企业赚不到钱，就不愿意投更多推广费。

一个人真正的成长一定是极其不容易的，如果想通过一两本书，一两个鸡汤文案，一两场培训就能够获得成长，那简直是痴人说梦，真正的成长一定不会是轻松的，一定是经过一次又一次的跌倒，然后爬起，对所做过的事，所经历的事进行一次又一次的复盘，总结，思考，最终才能慢慢认识到事物的本质，成长不是时间的堆积，也不会因为年龄递增而获得。

思考的难关

毫不夸张的说，思考是这个世界上最难的事，因为思考是要动脑的，而在现在这个信息爆炸的时代，我们想要任何资讯，任何知识，都可以找到现成的答案，所以懒惰就此滋生出来，“都有现成的答案了，我干嘛还要去动脑，我动脑得到的东西也未必有现成的好，而且动脑肚子还消耗能量，这种消耗不亚于体力劳动”，所以思考是最难的，而思考也是获取知识最快的途径。

我们在读书的时候，有些同学看似十分努力，一天感觉都是泡在书本里面的，但是成绩往往都不理想，初高中时，班上有些同学十分努力，对于我这种混子来说，我一定是扛不住的，就比如背英语单词，我发现有一些同学采用“原始人”的方式去背诵，因为我们整个初中换了三四个英语老师，而每个老师的教学方式不一样，其中一个老师就是教死记硬背，英语单词就比如“good”，她的方式是，“g o o d ， g o o d”，也就是一个字母一个字母的背诵，后来因为一些原因，又换了老师，老师又教了音标，但是最后我还是发现，很多同学依旧还是“g o o d”，后来我才发现，因为学音标还需要花时间，还要动点脑子，对于一个单词，还有不同的情况，所以还是司机硬背好，这种方式就是“蛮力”，其实只要稍微花点时间去研究一下音标，然后再好好学学，背单词就会轻松很多，所以初高中英语成绩一直比较好，当然，现在很差，词汇量很少，完全是后面吃了懒惰的大亏。

所以，思考虽然是痛苦的，但是熬过痛苦期，就能够飞速成长，如果沉浸在自我感动的蛮力式努力中，那么只会离成长越来越远。

懒惰的魔咒

说到懒惰，我们可能会想到睡懒觉，不努力学习，不努力工作，但这其实并不是懒惰，每天起得很早去搬砖，日复一日地干着重复的事，却没有半点成长，这才是真正的懒惰。

没有思考的勤快是一文不值的，在现在这个社会，各种工具十分普遍，如果我们依旧保持原始人的工作方式，那么最终只会把自己累死，就像很多统计工作，如果认为自己加班到十二点，人工统计出数据来，老板就会很欣赏你，觉得你很吃苦耐劳，那么这是愚蠢的，因为有很多工具可能五分钟就能够搞出来，可偏偏固执去搞一些没用的东西，这有用吗，还有现在是人工智能时代，各种GPT工具那么爽，直接让效率翻倍，但是我就是不用，我就喜欢自己从头搞，那也没办法。

很多时候，所谓的勤快不过是为了掩饰自己的懒惰而已，懒惰得不愿意去接受新的事物，不愿意去学习新东西，总觉得“老一套“万能。

成长过程中，要不断打破自己的认知，冲破自己的心灵上的懒惰，拥抱新鲜事物，这样才不至于和主流脱节。

环境的影响

在南瓜里度日,就成圆形;在竹子里生活,就成长形。

一个人的环境同样是塑造成长的重要因素。环境不仅指物理环境，也包括人际环境和心理环境。在环境中，我们需要学会适应和改变环境，让环境成为我们成长的动力。

人以类聚,物以群分，如果我们身边的人都是不思上进，终日惶惶，那么长时间下来，我们也会受影响，读书时，如果身边的同学都好学，那么自己也绝对不会变得很烂，相反，如果同学都整天无所事事，那么自己自然也不会好到哪里去，当身边的人都是勤于思考，有想法，那么大家就会有一个良好的氛围，这样成长得就比较快，工作中，如果大家都很有热情，分享很多，学习很多，那么自己也不好意思，自然也会去学习。

但是我们每个人的能力都不一样，所以遇到的环境也不一样，所以很多时候，这并不是我们能选择的，所以说在自己没能力选择的时候，那么就要克制自己，别人混，自己不能混，要时刻提醒自己不能松懈，也不要因为别人的闲言碎语而去”同流合污“，始终记住，一切都是为了自己变得更好，不要太在意别人的看法。

保持良好的心态

在这个浮躁的社会，我们的思想和意志总是被这个社会所影响，特别现在短视频如此火爆，”脉脉上面低于百万年薪不好意思发言，抖音上面人均劳斯莱斯，自己同学朋友又买了几套房“，我们的心态时不时会受到打击，原本平稳的步伐一下变得不稳了，想一步升天了，但是当步子迈大了，可能就受伤了。

我们要时刻提醒自己自己是为自己而活，无论别人是真还是假，和自己关系不大，不要被外界过于影响，这个世界上没有一个人的成功是轻易的，都是在黑暗中努力发光的，如果相信了速成，相信快速致富，那么镰刀造已经嫁到脖子上了，而且还割坏了很多把，一茬接着一茬！

即使此刻多么的不堪，也不要放弃，积累自己，也许有一天，我们再相逢，睁开眼睛看，我才是英雄，他日若遂凌云志，敢笑黄巢不丈夫！

今天的分享就到这里，感谢你的观看，我们下期见！

起因是这样的，我发现我的工资代扣个税，相较以前翻了三、四倍，工资也没给我涨呀，怎么交税还多了。怀疑给我算错了，于是我翻了翻资料找到一张税务总局的个人所得税税率表。

它是这样计算的：

1. 一年分成12个月，交纳税也分为12期



2. 本期应预扣预缴税额 = （累计预扣预缴应纳税所得额 * 税率 - 速算扣除数）- 累计已预扣预缴税额



3. 累计预扣预缴应纳税所得额 = 累计收入 - 累计免税收入 - 累计减除费用 - 累计专项扣除 - 累计专项附加扣除 -  累计依法确定的其他扣除



4. 其中，累计减除费用，按照5000元/月乘以纳税人当年截至本月在本单位的任职受雇月份数计算

举个例子，假设张三每月工资收入20000，各项社会保险金（五险一金）扣除为1000。

在八月份：

• 张三累计减除费用是5000*8=40000


• 累计专项扣除是1000*8=8000


• 排除张三有免税收入等情况，他的累计预扣预缴应纳税所得额为20000*8-40000-8000=112000，


• 累计预扣预缴应纳税所得额112000对应税率表的2级数，所以第八期应预扣预缴税额为(112000*0.1-2520)-累计已预扣预缴税额。


• 累计已预扣预缴税额是前7个月的纳税总和。这样计算，20000*7-5000*7-1000*7=98000 对应税率表的2级数，前7期累计已预扣预缴税额为98000*0.1-2520 = 7280


• 最后，张三在八月份，他要纳税为(112000*0.1-2520)-7280=1400

等等，文章还没完呢，不然又有人怼我纯水了。

我发现网络上像这类纳税计算器参差不齐，计算公式差得离谱，所以决定自己动手撸一个。

个税计算器

由于html、css、js代码内容长，所以我把这部分内容拼接成一张大图，也方便读源码。css布局大量使用Flex弹性布局，不了解的同学先学习一波《和我女神王冰冰一起学display: flex布局》。

描述下js逻辑层：

• 本月工资、社保（五险一金）、专项附加扣除都要乘以纳税期数，分别计算出各自的累计数


• 本月工资、社保（五险一金）、专项附加扣除、累计减除费用累计数相减计算后，就是累计预扣预缴应纳税所得额（累计应缴税款）


• 个人所得税税率表转化成taxRates数据结构，累计预扣预缴应纳税所得额作为参数调用getTaxRate方法返回税率、速算扣除数


• 累计已预扣预缴税额（已缴税款）计算为纳税期数减1，然后以减后的纳税期数再重复一遍上述计算过程


• 本期应预扣预缴税额（应交税额）= 累计预扣预缴应纳税*税率-速算扣除数-累计已预扣预缴税额（已缴税款）

布局兼容到了PC端、移动端，它们分别是这样的：

想要源码的同学，可以访问下面👇链接保存页面即可。

个税计算器在线链接：http://www.linglan01.cn/c/salary/

最后的话

文章中一类的个税计算器，一般计算出来的结果是有偏差的，原因如下：

• 每月工资不是固定的，受KPI影响工资会有一定起浮


• 奖金类的收入也要计算进去，如果有奖金没有计算进累计预扣预缴应纳税所得额，那计算的结果就是会偏差

所以说，个税计算器只能计算出大概的税。

想要准确的计算自己纳税情况，建议下载个人所得税APP。

当工资收入越高，应纳税所得额比重也会增大，比重在到一定程度后，我想我们应该要考虑如何合法避税。

每年年未都会有一次在个人所得税APP提交专项附加扣除，它能一定程度上补返回税额给我们。

另外，开通个人养老金帐户也可以进行一定额度的避税，将来养老滋不滋润重点看这个帐户。我收入还不足以供个人养老帐户，有条件、有需要的同学可以去了解一下。

如果我的文章对你有帮助，您的👍就是对我的最大支持^_^。

 

浏览器架构

1 浏览器的历史

单进程与多进程浏览器

在2007年之前，市面上浏览器都是单进程的，所有功能模块都是运行在同一个进程里，这些模块包含了网络、插件、JavaScript运行环境、渲染引擎和页面等。

最新的Chrome浏览器包括：1个浏览器（Browser）主进程、1个 GPU 进程、1个网络（NetWork）进程、多个渲染进程和多个插件进程

• 浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。


• 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎Blink和JavaScript引擎V8都是运行在该进程中，默认情况下，Chrome会为每个Tab标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。


• GPU进程。其实，Chrome刚开始发布的时候是没有GPU进程的。而GPU的使用初衷是为了实现3D CSS的效果，只是随后网页、Chrome的UI界面都选择采用GPU来绘制，这使得GPU成为浏览器普遍的需求。最后，Chrome在其多进程架构上也引入了GPU进程。


• 网络进程。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。


• 插件进程。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响

2 JavaScript的单线程模型

• 因为JS是与用户互动，以及操作DOM。如果JavaScript是多线程的，会带来很多复杂的问题，假如 JavaScript有A和B两个线程，A线程在DOM节点上添加了内容，B线程删除了这个节点，应该是哪个为准呢? 所以，为了避免复杂性，所以设计成了单线程。


• H5提供了多线程的方案：Web Worker, 他允许主线程创建worker线程，分配任务给worker进程处理，但是worker线程完全受到主线程控制，也不能操作DOM，没有改变JS的单线程本质。

3 Chrome 打开一个页面需要启动多少进程？分别有哪些进程？

打开 1 个页面至少需要 1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程，共 4 个；最新的 Chrome 浏览器包括：1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程。

• 浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。


• 渲染进程：核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。


• GPU 进程：其实，Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。


• 网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。


• 插件进程：主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

4 渲染机制

1. 浏览器如何渲染网页

概述：浏览器渲染一共有五步

1. 处理 HTML 并构建 DOM 树。


2. 处理 CSS构建 CSSOM 树。


3. 将 DOM 与 CSSOM 合并成一个渲染树。


4. 根据渲染树来布局，计算每个节点的位置。


5. 调用 GPU 绘制，合成图层，显示在屏幕上

第四步和第五步是最耗时的部分，这两步合起来，就是我们通常所说的渲染

具体如下图过程如下图所示

渲染

• 网页生成的时候，至少会渲染一次


• 在用户访问的过程中，还会不断重新渲染

重新渲染需要重复之前的第四步(重新生成布局)+第五步(重新绘制)或者只有第五个步(重新绘制)

• 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢


• 当 HTML 解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件。并且CSS也会影响 JS 的执行，只有当解析完样式表才会执行 JS，所以也可以认为这种情况下，CSS 也会暂停构建 DOM

知识点1

• 由于<script>标签是阻塞解析的，将脚本放在网页尾部会加速代码渲染。


• defer和async属性也能有助于加载外部脚本。


• defer使得脚本会在dom完整构建之后执行；


• async标签使得脚本只有在完全available才执行，并且是以非阻塞的方式进行的

知识点2: 重绘（Repaint）和回流（Reflow）

重绘和回流是渲染步骤中的一小节，但是这两个步骤对于性能影响很大

• 重绘是当节点需要更改外观而不会影响布局的，比如改变 color 就叫称为重绘


• 回流是布局或者几何属性需要改变就称为回流。

回流必定会发生重绘，重绘不一定会引发回流。回流所需的成本比重绘高的多，改变深层次的节点很可能导致父节点的一系列回流

以下几个动作可能会导致性能问题

• 改变 window 大小


• 改变字体


• 添加或删除样式


• 文字改变


• 定位或者浮动


• 盒模型

很多人不知道的是，重绘和回流其实和 Event loop 有关

• 当 Event loop 执行完Microtasks 后，会判断 document 是否需要更新。因为浏览器是 60Hz 的刷新率，每 16ms 才会更新一次。


• 然后判断是否有 resize 或者 scroll ，有的话会去触发事件，所以 resize 和 scroll 事件也是至少 16ms才会触发一次，并且自带节流功能。


• 判断是否触发了 media query


• 更新动画并且发送事件


• 判断是否有全屏操作事件


• 执行 requestAnimationFrame 回调


• 执行 IntersectionObserver 回调，该方法用于判断元素是否可见，可以用于懒加载上，但是兼容性不好


• 更新界面


• 以上就是一帧中可能会做的事情。如果在一帧中有空闲时间，就会去执行 requestIdleCallback 回调

常见的引起重绘的属性

• color


• border-style


• visibility


• background


• text-decoration


• background-image


• background-position


• background-repeat


• outline-color


• outline


• outline-style


• border-radius


• outline-width


• box-shadow


• background-size

3.4 常见引起回流属性和方法

任何会改变元素几何信息(元素的位置和尺寸大小)的操作，都会触发重排，下面列一些栗子

• 添加或者删除可见的DOM元素；


• 元素尺寸改变——边距、填充、边框、宽度和高度


• 内容变化，比如用户在input框中输入文字


• 浏览器窗口尺寸改变——resize事件发生时


• 计算 offsetWidth 和 offsetHeight 属性


• 设置 style 属性的值

回流影响的范围

由于浏览器渲染界面是基于流失布局模型的，所以触发重排时会对周围DOM重新排列，影响的范围有两种

• 全局范围：从根节点html开始对整个渲染树进行重新布局。


• 局部范围：对渲染树的某部分或某一个渲染对象进行重新布局

全局范围回流

<body>

  <div class="hello">

    <h4>hello</h4>

    <p><strong>Name:</strong>BDing</p>

    <h5>male</h5>

    <ol>

      <li>coding</li>

      <li>loving</li>

    </ol>

  </div>

</body>

当p节点上发生reflow时，hello和body也会重新渲染，甚至h5和ol都会收到影响

局部范围回流

用局部布局来解释这种现象：把一个dom的宽高之类的几何信息定死，然后在dom内部触发重排，就只会重新渲染该dom内部的元素，而不会影响到外界

3.5 减少重绘和回流

使用 translate 替代 top

<div class="test"></div>

<style>

    .test {

        position: absolute;

        top: 10px;

        width: 100px;

        height: 100px;

        background: red;

    }

</style>

<script>

    setTimeout(() => {

        // 引起回流

        document.querySelector('.test').style.top = '100px'

    }, 1000)

</script>



 

        @程序员poetry: 代码已经复制到剪贴板

    

• 使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流（改变了布局）


• 把 DOM 离线后修改，比如：先把 DOM 给 display:none (有一次 Reflow)，然后你修改100次，然后再把它显示出来


• 不要把 DOM 结点的属性值放在一个循环里当成循环里的变量

for(let i = 0; i < 1000; i++) {

    // 获取 offsetTop 会导致回流，因为需要去获取正确的值

    console.log(document.querySelector('.test').style.offsetTop)

}



 

        @程序员poetry: 代码已经复制到剪贴板

    

• 不要使用 table 布局，可能很小的一个小改动会造成整个 table 的重新布局


• 动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame


• CSS选择符从右往左匹配查找，避免 DOM深度过深


• 将频繁运行的动画变为图层，图层能够阻止该节点回流影响别的元素。比如对于 video标签，浏览器会自动将该节点变为图层。

谈谈SSO单点登录的设计实现

本篇将会讲讲单点登录的具体实现。

实现思路

其实单点登录在我们生活中很常见，比如学校的网站，有很多个系统，迎新系统，教务系统，网课系统。我们往往只需要登录一次就能在各个系统中被认定为登录状态。

这是怎么实现的？我们需要一个认证中心，一如学校网站也有一个统一认证中心，也就是我们的SSO的Server端。在每个系统也就是Client端，我们只要判断已经在这个认证中心中登录，那我们就会被设置为登录状态。

再来就是最后一个问题了，我们判断在认证中心登录后，怎么在其他系统中也登录？

这个问题其实就是单点登录中最麻烦的问题了，也就是如何传播我们的登录状态。

我们可以分为两个情况Cookie共享传播状态，url参数传播状态。

Cookie共享传播状态

第一种情况：我们的认证中心和其他系统是在一个域名下的，认证中心为父域名(jwxt.com)，其他系统是子域名(yx.jwxt.com)，或者是同一IP不同端口的情况，我们的服务端通过cookie去判断是否登录。

在这种情况下我们只要在认证中心登录成功的时候设置Cookie，当然设置Cookie的时候也要注意设置好你的Cookie参数。

要注意设置的参数是domin，path。这两个参数值决定了Cookie的作用域。domin要设置为父域名(.jwxt.com)。当然还要注意一个SameSite参数，不能设置为。(如果为，你在baidu.com登录，在example.com网站如果你点击了 baidu.com/delete 链接，会带着你在baidu.com的Cookie访问。)

设置完Cookie，子域名的系统也有了Cookie，自然就会被服务端判断为登录状态。

简而言之，就是利用Cookie共享来实现登录状态的传播。

url参数传播状态

第二种我们的认证中心和其他系统不在一个域名下的，或者是不同IP的情况。

为了安全浏览器限制cookie跨域，也就是说第一种方法就不管用了。

这种情况可以通过传播参数来实现，也就是在认证中心登录后带着 登录凭证(token) 重定向到对应的Client页面，然后我们的前端就可以用js获取到url中的token进行存储(设置到Cookie或者localstorage等方式)，之后我们的服务端只需要通过这个token就可以判断为登录状态了。

当然，为了安全我们往往不会直接传递凭证，而是传递一个校验码ticket，然后前端发送ticket到服务端校验ticket，校验成功，就进行登录，设置Cookie或者存储token。

流程

接下来我们梳理一下流程，一下Client为需要单点登录的系统，Server为统一认证中心。

Cookie共享传播状态

1. 用户在Client1，如果没有登录，跳转到Server，判断在Server是否登录，如果判断没有登录，要求登录，登录成功后设置Cookie，跳转Client


2. Client1登录成功

如果之后在Client2页面，由于共享Cookie，当然也是登录状态。

url参数传播状态

1. 用户在Client1，判断没有登录，跳转到Server，判断在Server是否登录，如果没有登录，要求登录，登录成功后设置Cookie，带着ticket跳转Client。


2. 到了Client1，前端通过参数获取到ticket，发送到服务端，服务端校验ticket获取登录id，设置Cookie进行登录。

之后在Client2页面

1. 用户在Client2，判断没有登录，跳转到Server，判断在Server是否登录，这时候判断为登录，带着ticket(或者token)跳转Client。


2. 到了Client2，前端通过参数获取到ticket，发送到服务端，服务端校验ticket获取登录id，设置Cookie进行登录。

如果不使用ticket校验就直接存储传播过来的登录凭证即可，当然如果你不存储到Cookie，记得在请求后端服务的时候带上token。

ticket校验

再说说ticket校验

ticket校验根据情况也可以分为两种，一种情况是Server和Client的后端共用的同一个Redis或者Redis集群，可以直接向Redis请求校验。如果后端用的Redis不同，可以发送http请求到Server端在Server端校验。

到此，单点登录就完成了。

当然在以上描述中的Cookie你也可以不使用，使用Cookie主要是方便，在请求后端时会自动发送。你只需要存储到localstorage/sessionstorage等地方，请求后端的时候记得get然后带上即可。