乐趣区

关于javascript:用JavaScript写一个彩票系统

本来这篇文章是打算叫「如果我是彩票零碎开发者」,但细想一下,如果在文章中援用太多的 JavaScript 的话,反而不是那么纯正,毕竟也只是我的两厢情愿,彩票开发也不全如本文所讲,有所误导的话便也是得失相当了。

所以索性就叫「用 JavaScript 写出一个彩票零碎」,也算清朗了一些,申明一下,实在的彩票零碎不是这么开发进去的,也不具备明面上的法则,咱们应该置信彩票的公正性,只管其可能不是基于随机!

杂谈

最近大抵是迷上彩票了,空想着本人若能暴富,也能够带着家庭 ” 鸡犬升天 ” 了,不过大失所望,我并没有冲天的气运,踏踏实实工作才是前途?

买彩票的时候,我也思考了很久,到底怎么样的号码能够在 1700 万注中怀才不遇,随机试过,精心筛选的也试过,找法则的模式也试过,甚至我还用到了爬虫去统计数据,啼笑人非!

咱们默认彩票零碎是基于统计学来实现一等奖的开奖,那么历史以来的一等奖天经地义应该是当期统计率最低的一注,所以,最开始的时候我是这么想的:

  1. 获取历史以来所有的中奖彩票号码
  2. 应用代码去统计出所有号码的中奖次数
  3. 依照呈现几率最低的数字来排序
  4. 顺次组成某几注新号码

天马行空,却也是本人发财欲望的一种发泄渠道罢了,称之为胡思乱想也不为过,扯了挺多,哈哈!

下面的思路我曾经实际过了,用了差不多一年的工夫,没有用!别用!当然你也能够试试,如果你中了,祝贺,你才是天选之人!

彩票的规定

咱们这里的彩票规定对立应用「双色球」的规定来阐明,其购买的规定如下:

  1. 红球为六位,选项从 1 – 33 中筛选,不可反复
  2. 蓝球为一位,选项从 1 – 16 中筛选
  3. 红蓝双色球一共七位组成一注

一等奖个别中全副购买的注外面筛选一注,这一注可能被多集体买,也有可能是一个人买了该注的倍数。

所以粗略统计,彩票的中奖几率计算公式如下所示:

应用组合数公式来计算,从 n 个元素中取 k 个元素的的组合数公式为:

$$C\binom{k}{n}=\frac{n!}{k!(n-k)!}$$

依据公式,咱们能够很容易的写进去一个简略的算法:

function factorial(n) {if (n === 0 || n === 1) {return 1} else {return n * factorial(n - 1)
  }
}

function combination(n, k) {return factorial(n) / (factorial(k) * factorial(n - k))
}

console.log(combination(33, 6) * combination(16, 1)) // 17721088

所以能够得出的论断是,双色球头奖的中奖几率为:
$$\frac{1}{17721088}$$

数据量

咱们通过下面的算法得悉了彩票的总注数为 17721088,那么这么多注数字组成的数据到底有多大呢?

简略计算下,一注彩票能够用 14 个数字来示意,如 01020304050607,那么在操作系统中,这串数字的大小为 14B,那么粗略可知的是,如果所有的彩票注数都在一个文件中,那么这个文件的大小为:

const totalSize = 17721088 * 14 / 1024 / 1024 // 236.60205078125MB

很恐怖的数量,有没有可能更小?咱们钻研一下压缩算法!

01这个数字在内存中的占用是两个字节,也就是 2B,那如果咱们把 01 用小写 a 代替,那么其容量就能够变成 1B,总体容量可缩小一半左右!

这样子的话,咱们下面的一注特地牛的号码 01020304050607 就能够示意为 abcdefg !

这就是压缩算法最最最根本的原理,压缩算法有很多种,大体分为有损压缩和无损压缩,对于咱们数据类的内容来讲,咱们个别都会抉择无损压缩!

  • 有损压缩算法:这些算法可能在压缩数据时抛弃一些信息,但通常能在不影响理论应用的前提下实现更高的压缩比率,其中最常见的是图像、音频和视频压缩算法
  • 无损压缩算法:这些算法不会抛弃任何信息,它们通过查找输出数据中的反复模式,并应用更短的符号来示意它们来实现压缩。无损压缩算法罕用于文本、代码、配置文件等类型的数据

首先,让咱们先筹备一些测试数据,咱们应用上面这个简略的组合数生成算法来获取出 1000 个组合数:

function generateCombinations(arr, len, maxCount) {let result = []
  
  function generate(current, start) {
    // 如果曾经生成的组合数量达到了最大数量,则进行生成
    if (result.length === maxCount) {return}

    // 如果以后曾经生成的组合长度等于指定长度,则示意曾经生成了一种组合
    if (current.length === len) {result.push(current)
      return
    }

    for (let i = start; i < arr.length; i++) {current.push(arr[i])
      generate([...current], i + 1)
      current.pop()}
  }

  generate([], 0)
  return result
}

接下来,咱们须要生成 1000 注双色球,红球是从 1 – 33 中取组合数,蓝球是从 1 – 16 中顺次取数

function getDoubleColorBall(count) {// 红球数组:['01', '02' .... '33']
  const arrRed = Array.from({length: 33}, (_, index) => (index + 1).toString().padStart(2, '0'))
  const arrRedResult = generateCombinations(arrRed, 6, count)

  const result = []
  let blue = 1
  arrRedResult.forEach(line => {result.push(line.join('') + (blue++).toString().padStart(2,'0'))
    if (blue > 16) {blue = 1}
  })

  return result
}

咱们将获取的彩票内容放在文件中以便于下一步操作:

const firstPrize = getDoubleColorBall(1000).join('')
fs.writeFileSync('./hello.txt', firstPrize)

这样子,咱们就失去了第一版的文件,这是其文件大小:

试一下咱们初步的压缩算法,咱们将刚刚设定好的规定,也就是数字到字母的替换,用 JavaScript 实现进去,如下:

function compressHello() {
  const letters = 'abcdefghijklmnopqrstuvwxyzABCDEFG'
  const doubleColorBallStr = getDoubleColorBall(1000).join('')
  let resultStr = ''
  for (let i = 0; i < doubleColorBallStr.length; i+=2) {const number = doubleColorBallStr[i] + doubleColorBallStr[i+1]
    resultStr += letters[parseInt(number) - 1]
  }
  return resultStr
}

const firstPrize = compressHello()
fs.writeFileSync('./hello-1.txt', firstPrize)

这样咱们就失去了一个全新的 hello 文件,他的大小如下所示,正好印证了咱们的想法!

如果依照这个算法的办法,咱们能将之前的文件压缩至一半大小,也就是 118.301025390625MB,然而这就是极限了吗?不,下面咱们讲过,这只是最根本的压缩,接下来,让咱们试试更精妙的办法!

更精妙的办法

这里咱们不对压缩算法的原理做过多的解释,如果诸位感兴趣的话,能够本人寻找相似的文章浏览,鉴于网上的文章品质参差不齐,我就不做举荐了!

这里咱们须要理解的是,咱们正在钻研的是一个彩票零碎,所以他的数据压缩应该具备以下几个特色:

  • 具备数据不失落的个性,也就是无损压缩
  • 压缩率尽可能小,因为传输的文件可能十分大,如咱们下面举的例子
  • 便于信息的传输,也就是反对 HTTP 申请

常做前端的同学应该晓得,咱们在 HTTP 申请头外面常见的一个参数 content-encoding: gzip,在我的项目的优化方面,也会抉择将资源文件转换为 gzip 来进行散发。在日常的应用中,咱们也时常依赖 WebpackRollup 等库,或者通过网络服务器如 nginx 来实现资源压缩,gzip 不仅能够使得发送的内容大大减少,而且客户端能够无损解压拜访源文件。

那么,咱们能不能应用 gzip 来实现压缩呢?答案是能够,Node.js 为咱们提供了 zlib 工具库,提供了相应的压缩函数:

const zlib = require('zlib')

const firstPrize = compressHello()
fs.writeFileSync('./hello-2.txt.gz', zlib.gzipSync(firstPrize))

失去的后果是:

咱们实现了 14KB -> 3KB 的压缩过程!是不是很有意思?不过还是那句话,有没有可能更小?当然能够!

content-encoding 响应头个别是服务器针对返回的资源响应编码格局的设置信息,常见的值有以下三种:

  • gzip 所有浏览器都反对的通用压缩格局
  • brotligzip 压缩性能更好,压缩率更小的一个新的压缩格局,老版本浏览器不反对
  • deflate 出于某些起因,应用不是很宽泛,后有基于该算法的 zlib 压缩格局,不过也应用度不高

浏览器反对的压缩格局不只是这些,不过咱们列举出的是较为罕用的,咱们尝试应用一下这三种压缩格局:

const firstPrize = compressHello()
fs.writeFileSync('./hello-2.txt.gz', zlib.gzipSync(firstPrize))
fs.writeFileSync('./hello-2.txt.def', zlib.deflateSync(firstPrize))
fs.writeFileSync('./hello-2.txt.br', zlib.brotliCompressSync(firstPrize))

咱们能够看到,deflategzip 的压缩率并驾齐驱,令人惊喜的是,brotli的压缩居然达到了惊人的 1KB ! 这不就是咱们想要的吗?

还可能更小吗?哈哈哈哈,当然,如果不思考 HTTP 反对,咱们齐全能够应用如 7-zip 等压缩率更低的压缩算法去实现压缩,而后应用客户端做手动解压。不过点到为止,更重要的工作咱们还没有做!

在这之前,咱们须要先理解一下解压过程,如果解压后反而数据失落,那就得失相当了!

// 执行解压操作
const brFile = fs.readFileSync('./hello-2.txt.br')
const gzipFile = fs.readFileSync('./hello-2.txt.gz')
const deflateFile = fs.readFileSync('./hello-2.txt.def')

const brFileStr = zlib.brotliDecompressSync(brFile).toString()
const gzipFileStr = zlib.gunzipSync(gzipFile).toString()
const deflateFileStr = zlib.inflateSync(deflateFile).toString()

console.log(brFileStr)
console.log(gzipFileStr)
console.log(deflateFileStr)

console.log(brFileStr === gzipFileStr, brFileStr === deflateFileStr) // true, true

如上,咱们通晓只管压缩算法的成果很惊人,然而其解压后的数据仍然是无损的!

残缺的数据

让咱们构建出残缺的 17721088 注数据测试一下残缺的压缩算法的能力如何?这里咱们应用 brotligzip 算法别离进行压缩测试!

首先,应该批改咱们生成数据的函数,如下:

function generateAll() {const arrRed = Array.from({ length: 33}, (_, index) => (index + 1).toString().padStart(2, '0'))
  const arrRedResult = generateCombinations(arrRed, 6, Number.MAX_VALUE)

  const result = []
  arrRedResult.forEach(line => {for (let i = 1; i <= 16; i++) {result.push(line.join('') + i.toString().padStart(2,'0'))
    }
  })

  return result
}

console.log(generateAll().length) // 17721088

接下来咱们要通过初步压缩并将其写入文件中:

function compressAll() {
  const letters = 'abcdefghijklmnopqrstuvwxyzABCDEFG'
  const allStr = generateAll().join('')
  let resultStr = ''
  for (let i = 0; i < allStr.length; i += 2) {const number = allStr[i] + allStr[i+1]
    resultStr += letters[parseInt(number) - 1]
  }
  return resultStr
}

const firstPrize = compressAll()
fs.writeFileSync('./all-ball.txt', firstPrize)

正如咱们意料的,通过初步压缩之后,文件大小达到了大概 118MB,然而其理论占用 124MB,是属于计算机存储的领域,咱们当初不在本篇文章中探讨,感兴趣的同学能够本人查一查,依据字节数计算,其大小为:

const totalSize = 124047616 / 1024 / 1024 // 118.30102539 MB

目前来看是合乎预期的,咱们来看看两个压缩算法的真本事!

const firstPrize = compressAll()
fs.writeFileSync('./all-ball.txt.gz', zlib.gzipSync(firstPrize))
fs.writeFileSync('./all-ball.txt.br', zlib.brotliCompressSync(firstPrize))

其实是很震惊的一件事件,只管我对 brotli 的期待足够高,也不会想到他能压缩到仅仅 4M 大小,不过对于咱们来说,这是一件幸事,对于之后的散发操作有微小的劣势!

随机来两注

从彩票站购买彩票的时候,随机来两注的行为是十分常见的,然而当你尝试随机号码的时候,会产生什么呢?

咱们先从彩票数据的散发讲起,首先彩票数据的散发安全性和稳定性的设计必定是毋庸置疑的,然而这不是咱们目前须要思考的问题,目前咱们应该解决的是,如果能力更低水平的管制老本!

假如设计这套零碎的人是你,如果管制随机号码的中奖率?我的答案是,从已有的号码池外面进行抉择!

如果让每个彩票站获取到其对应的号码池,答:数据散发!如果采纳数据散发的模式的话,须要思考的问题如下:

  • 什么时候进行散发
  • 数据回源如何做
  • 如何防止所有数据被劫持
  • 数据交给彩票站的策略

据 2021 年公开信息,彩票站的数量曾经达到 20 万家(未查证,无参考价值),咱们假如目前的彩票站数量为 30 万家!

什么时候进行散发

咱们晓得的是,彩票的购买截止工夫是在早晨八点,开奖工夫是在早晨的九点十五,在早晨八点之后,咱们只能购买到下一期的彩票,那么这个节点应该从早晨的八点开始,打算是这样子的:

  1. 从目前已有的彩票库外面,依照号码呈现几率从高到低排列
  2. 挑选出前 50 万注分发给 30 万彩票站,这个工夫彩票站的数据都是对立的
  3. 每个小时同步一次数据,同步的是其余彩票站 ” 特意筛选的数据 ”

50 万注的数据量有多大?试试看:

function getFirstSend() {
  const letters = 'abcdefghijklmnopqrstuvwxyzABCDEFG'
  const doubleColorBallStr = getDoubleColorBall(500000).join('')
  let resultStr = ''
  for (let i = 0; i < doubleColorBallStr.length; i+=2) {const number = doubleColorBallStr[i] + doubleColorBallStr[i+1]
    resultStr += letters[parseInt(number) - 1]
  }
  return resultStr
}

const firstPrize = getFirstSend()
fs.writeFileSync('./first-send.txt.br', zlib.brotliCompressSync(firstPrize))

仅一张图片的大小,获取这些数据解压同步到彩票机工夫有余 1s!

解压示例如下:

function decodeData(brFile) {const result = []
  const content = zlib.brotliDecompressSync(brFile)
  // 依照七位每注的构造拆分
  for (let i = 0; i < content.length; i += 7) {result.push(content.slice(i, i + 8))
  }
  return result
}

const firstSend = fs.readFileSync('./first-send.txt.br')
const firstDataList = decodeData(firstSend)
console.log(firstDataList.length) // 500000

如何将获取到的字符模式的彩票转换为数字,如 abcdefga 转换为 ['01', '02', '03', '04', '05', '06,'01']

function letterToCode(letterStr) {const result = []
  const letters = 'abcdefghijklmnopqrstuvwxyzABCDEFG'
  for (let i = 0; i < letterStr.length; i++) {result.push((letters.indexOf(letterStr[i]) + 1).toString().padStart(2, '0'))
  }
  return result
}

至于散发?咱们能够参考一下市面上已有的一些概念做一下比照,上面是抽象的一个网络服务器的 TPS 预估值,也就是说彩票服务器在 1 秒内能够解决的最大申请数:

  • 低性能:TPS 在 50 以下,实用于低流量的利用场景,例如集体博客、小型企业网站等。
  • 中性能:TPS 在 50~500 之间,实用于个别的网站和利用场景,例如中小型电商网站、社交网络等。
  • 高性能:TPS 在 500~5000 之间,实用于高流量的网站和利用场景,例如大型电商网站、游戏网站等。
  • 超高性能:TPS 在 5000 以上,实用于超高流量的网站和利用场景,例如互联网巨头的网站、在线游戏等。

依照这种模式的话,50 万彩票站的数据同步在 100 秒内就能够实现,当然,诸位,这里是单机模式,如果做一个彩票服务的话,单机必定是不可能的,想要进步 TPS,那就做服务器集群,如果有 100 台服务器集群的话,解决这些申请仅仅须要 1 秒!(任性吗?有钱当然能够任性!)(这些数据的得出都是基于实践,不提供参考价值)

数据回源如何做

非常简单!咱们须要获取的数据是哪一些呢?没有通过随机算法,间接被购买的彩票数据!也就是咱们常常听到的 ” 守号 ” 的那些老彩民!

同样,依据媒体查问得悉(不做参考),彩票站的客流量是每小时 1 至 10 人,经营工夫,早上九点至早晨九点,最大客流量预计为 100 人每天!

那么所有彩票站的总体客流量在 100 * 500000 = 50000000,大概为五千万人次,大概有 50% 是属于 ” 守号 ” 人,这外面可能还须要排除掉彩票站中已知的号码,不过在这里咱们先不解决,先做全副的预估,那么

服务器须要承载的最大 TPS 为:

// 服务器集群数量
const machineCount = 100
// 总访问量,50% 中的号码才会上报
const totalVisit = 50000000 * 0.5 // 25000000
// 总的工夫,因为咱们计算的是 10 个小时的工夫,所以应该计算的总秒数为 36000 秒!const totalSeconds = 10 * 60 * 60

console.log(totalVisit / totalSeconds / machineCount) // 6.944444444444445

TPS 仅为 7 !!这还是没有排除掉曾经知悉的号码的状况,具体的上报逻辑,参考下图:

数据交给彩票站的策略(防止数据被劫持)

所有的彩票数据当然不能全副都交给彩票站,咱们须要对所有的数据做一个分层,其余彩票站 ” 特意筛选的数据 ” 就是咱们要分层散发的数据!这样子也就能解决 “ 如何防止所有数据被劫持 ” 的问题!

那么咱们如何对数据进行分层呢?

简而言之,就是咱们将陕西西安彩票站的购票信息同步给山西太原,将上海市购票信息同步给江苏苏州!当然这外面须要思考的点十分多,不仅仅是两地数据的替换,逻辑也比较复杂,通常须要思考的点是:

  • 数据同步难度,跨地区同步对服务器压力微小,如华南向华北同步
  • 数据类似水平,两地的数据如果历史以来类似度区别很大,反而不能达到笼罩的目标,因为咱们最终是想要这注号码被购买更屡次
  • 数据同步时差,如新疆等地,鉴于网络问题,比其余地要慢很多的状况,这样就会漏号,那么就应该把这些中央的数据同步到更热闹的区域,如上海市,然而这一点看似是和第一二点相悖的

就说这么多,说的多了其实我也不懂。或者说还没想进去,如果有这方面比拟厉害的大佬,能够提供思路!咱们先看看随机的号码后果如何:

咱们来尝试随机获取你须要的两注:

function random(count) {let result = []
  for (let i = 0; i < count; i++) {const index = Math.floor(Math.random() * firstDataList.length)
    console.log(firstDataList[index])
    result.push(letterToCode(firstDataList[index]))
  }
  return result
}

console.log(random(2))

OK,你感觉能够中奖吗?哈哈哈,还是有可能的,持续往下看吧!

特意挑的两注

我是一个典型的 ” 守号 ” 人,每天都拿着本人算进去的几注号码,去购买彩票,那么我能够中奖吗?(目前没中)

依据下面的形容,咱们应该晓得,” 守号 ” 人购买的号码须要判断零碎是否存在数据,如果存在的话,就不会触发上报,如果数据不存在,则会上报零碎,由零碎将以后号码分发给相邻市或数据近似的城市,预期以后号码能够被更多的人所购买,一注号码如果被购买的越多,其中奖的概率也就越低!

不过特意筛选是要比随机筛选的中奖概率要大,然而也大不到哪里去。

我要一等奖

彩票的一等奖是基于统计的,即便彩票核心存在空号,也须要思考空号所产生的二等奖至六等奖的数量,这是一个十分宏大的数据量,也是须要计算十分多的工夫的,那么咱们如何模仿呢?

咱们取 50 万注彩票,模仿一下这些彩票被购买的状况,可能会产生空号,可能会反复购买,或者购买多注等,尝试一下计算出咱们须要付出的总金额!

彩票中中奖规定是这样子的,浮动奖项咱们临时不思考,给一等奖和二等奖都赋予固定的金额:

  1. 6 + 1 一等奖 奖金 500 万
  2. 6 + 0 二等奖 奖金 30 万
  3. 5 + 1 三等奖 奖金 3000 元
  4. 5 + 0 或 4 + 1 四等奖 奖金 200 元
  5. 4 + 0 或 3 + 1 五等奖 奖金 10 元
  6. 2 + 1 或 1 + 1 或 0 + 1 都是 六等奖 奖金 5 元

依据这个规定,咱们能够先写出对奖的函数:

/**
 * @param {String[]} target ['01', '02', '03', '04', '05', '06', '07']
 * @param {String[]} origin ['01', '02', '03', '04', '05', '06', '07']
 * @returns {Number} 返回以后彩票的中奖金额
 */
function compareToMoney(target, origin) {
  let money = 0
  let rightMatched = target[6] === origin[6]
  // 求右边六位的交加数量
  let leftMatchCount = target.slice(0, 6).filter(c => origin.slice(0,6).includes(c)
  ).length

  if (leftMatchCount === 6 && rightMatched) {money += 5000000} else if (leftMatchCount === 6 && !rightMatched) {money += 300000} else if (leftMatchCount === 5 && rightMatched) {money += 3000} else if (leftMatchCount === 5 && !rightMatched) {money += 200} else if (leftMatchCount === 4 && rightMatched) {money += 200} else if (leftMatchCount === 4 && !rightMatched) {money += 10} else if (leftMatchCount === 3 && rightMatched) {money += 10} else if (leftMatchCount === 2 && rightMatched) {money += 5} else if (leftMatchCount === 1 && rightMatched) {money += 5} else if (rightMatched) {money += 5}
  return money
}

那么,应该如何失去利益最大化,步骤应该是这样子:

  • 随机生成一组中奖号码
  • 对于每个购买的数字,查看是否与中奖号码匹配,并计算它的奖金金额
  • 对于所有购买的数字的奖金金额进行求和
  • 反复这个过程,直到找到最优的中奖号码

随机这个中奖号码十分重要,他决定着咱们计算出整体数据的速度,所以咱们依照上面的步骤进行获取:

  • 将所有的号码依照购买数量进行排序(其实这里实在的场景应该联结思考中奖号码的散布趋势才更准确)
  • 从空号开始查问,顺次进行计算

先模拟出咱们的购买数据:

function getRandomCode(count = 500000) {const arrRed = Array.from({ length: 33}, (_, index) => (index + 1).toString().padStart(2, '0'))
  // generateCombinations 是咱们下面定义过的函数
  const arrRedResult = generateCombinations(arrRed, 6, count)

  const result = []
  let blue = 1
  arrRedResult.forEach(line => {result.push([...line, (blue++).toString().padStart(2, '0')])
    if (blue > 16) {blue = 1}
  })

  return result
}

function randomPurchase() {const codes = getRandomCode()
  const result = []
  for (let code of codes) {let count = Math.floor(Math.random() * 50)
    result.push({
      code,
      count,
    })
  }
  return result
}

console.log(randomPurchase())

咱们将失去相似于上面的数据结构,这对于统计来说较为不便:

[
  {
    code: [
      '01', '02',
      '03', '04',
      '05', '10',
      '05'
    ],
    count: 17
  },
  {
    code: [
      '01', '02',
      '03', '04',
      '05', '11',
      '06'
    ],
    count: 4
  }
]

接下来,就是很简略的统计了,逻辑很简略,但对于数据量极为宏大的彩票来说,须要的工夫!

// 空号在前,购买数量越多越靠后
const purchaseList = randomPurchase().sort((a, b) => a.count - b.count)
const bonusPool = []

for (let i = 0; i < purchaseList.length; i++) {
  // 假如这就是一等奖,那么就须要计算其价值
  const firstPrize = purchaseList[0]
  let totalMoney = 0

  for (let j = 0; j < purchaseList.length; j++) {
    // 与一等奖进行比照,比照规定是参照彩票中奖规定
    const money = compareToMoney(purchaseList[j].code, firstPrize.code) * purchaseList[j].count
    totalMoney += money
  }

  bonusPool.push({
    code: firstPrize.code,
    totalMoney,
  })
}

const result = bonusPool.sort((a, b) => a.totalMoney - b.totalMoney)
// 至于怎么挑,那就得心应手了
console.log(result[0].code, result[0].totalMoney)

至于最初的一等奖怎么挑,那就得心应手了,不过下面的算法在我的 M1 芯片计算须要的工夫也将近 10 分钟,如果有更弱小的机器,更厉害的算法,这个时长同样能够缩短,不开展了,累了,就这样吧!

黄粱一梦

终归是黄粱一梦,最终还是要回归生存,好好工作!不过谁晓得呢,等会再买一注如何?

彩票零碎纯属臆测,不可能有雷同!

结语

我是泰罗凹凸曼,M78 星云最爱写代码的,咱们下一篇再会!

去摸索,不晓得的货色还多着呢!

退出移动版