[] == false 和 !![] == true 解析

==是相等操作符,先转换再比较;===是全等操作符,仅比较不转换。

[] == false 解析

右侧布尔值很简单,直接转换成 0

[] 不是基本数据类型,它是对象,所以需要调用 valueOf 方法(Array.prototype.valueOf() ,但是 Array 没有实现 valueOf 方法,所以根据原型链,最终调用的是 Object.prototype.valueOf):

[].valueOf():得到的仍然是 [] ,继续调用 toString 方法(Array.prototype.toString()):

[].toString():得到""

""作为基本数据类型直接调用 Number("") 得到 0

所以最终结果是 true


!![] == true

!!== 的优先级更高,所以先看 !![]

![] 得到 false (操作数是对象的话逻辑非返回 false),然后再取非,得到 true

很明显,true == true 得到的结果是 true

npm、yarn、pnpm 各自区别

npm logo
npm logo

npm

npm是围绕着语义版本控制的思想而设计的,给定一个版本号:主版本号.次版本号.补丁版本号, 以下这三种情况需要增加相应的版本号:

主版本号: 当API发生改变,并与之前的版本不兼容的时候
次版本号: 当增加了功能,但是向后兼容的时候
补丁版本号: 当做了向后兼容的缺陷修复的时候
npm使用一个名为 package.json 的文件,用户可以通过 npm install --save 命令把项目里所有的依赖项保存在这个文件里。

例如,运行 npm install --save lodash 会将以下几行添加到 package.json 文件中。

"dependencies": {
    "lodash": "^4.17.4"
}

扁平的 node_modules 结构

为了将嵌套的依赖尽量打平,避免过深的依赖树和包冗余,npm v3 将子依赖「提升」,采用扁平的 node_modules 结构,子依赖会尽量平铺安装在主依赖项所在的目录中。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
    └── node_modules
        └── B@2.0.0

可以看到 A 的子依赖的 B@1.0 不再放在 A 的 node_modules 下了,而是与 A 同层级。

而 C 依赖的 B@2.0 因为版本号原因还是嵌套在 C 的 node_modules 下。

这样不会造成大量包的重复安装,依赖的层级也不会太深,解决了依赖地狱问题,但也形成了新的问题。

幽灵依赖 Phantom dependencies

幽灵依赖是指在 package.json 中未定义的依赖,但项目中依然可以正确地被引用到。

比如上方的示例其实我们只安装了 A 和 C:

{
  "dependencies": {
    "A": "^1.0.0",
    "C": "^1.0.0"
  }
}

由于 B 在安装时被提升到了和 A 同样的层级,所以在项目中引用 B 还是能正常工作的。

幽灵依赖是由依赖的声明丢失造成的,如果某天某个版本的 A 依赖不再依赖 B 或者 B 的版本发生了变化,那么就会造成依赖缺失或兼容性问题。

不确定性 Non-Determinism

不确定性是指:同样的 package.json 文件,install 依赖后可能不会得到同样的 node_modules 目录结构。

还是之前的例子,A 依赖 B@1.0,C 依赖 B@2.0,依赖安装后究竟应该提升 B 的 1.0 还是 2.0。

node_modules
├── A@1.0.0
├── B@1.0.0
└── C@1.0.0
└── node_modules
└── B@2.0.0

node_modules
├── A@1.0.0
│ └── node_modules
│ └── B@1.0.0
├── B@2.0.0
└── C@1.0.0

取决于用户的安装顺序。

如果有 package.json 变更,本地需要删除 node_modules 重新 install,否则可能会导致生产环境与开发环境 node_modules 结构不同,代码无法正常运行。

依赖分身 Doppelgangers

假设继续再安装依赖 B@1.0 的 D 模块和依赖 @B2.0 的 E 模块,此时:

A 和 D 依赖 B@1.0
C 和 E 依赖 B@2.0
以下是提升 B@1.0 的 node_modules 结构:

node_modules
├── A@1.0.0
├── B@1.0.0
├── D@1.0.0
├── C@1.0.0
│ └── node_modules
│ └── B@2.0.0
└── E@1.0.0
└── node_modules
└── B@2.0.0

可以看到 B@2.0 会被安装两次,实际上无论提升 B@1.0 还是 B@2.0,都会存在重复版本的 B 被安装,这两个重复安装的 B 就叫 doppelgangers。

而且虽然看起来模块 C 和 E 都依赖 B@2.0,但其实引用的不是同一个 B,假设 B 在导出之前做了一些缓存或者副作用,那么使用者的项目就会因此而出错。


yarn logo

yarn

2016 年,yarn 发布,yarn 也采用扁平化 node_modules 结构。它的出现是为了解决 npm v3 几个最为迫在眉睫的问题:依赖安装速度慢,不确定性。

提升安装速度

在 npm 中安装依赖时,安装任务是串行的,会按包顺序逐个执行安装,这意味着它会等待一个包完全安装,然后再继续下一个。

为了加快包安装速度,yarn 采用了并行操作,在性能上有显著的提高。而且在缓存机制上,yarn 会将每个包缓存在磁盘上,在下一次安装这个包时,可以脱离网络实现从磁盘离线安装。

lockfile 解决不确定性

yarn 更大的贡献是发明了 yarn.lock

在依赖安装时,会根据 package.josn 生成一份 yarn.lock 文件。

lockfile 里记录了依赖,以及依赖的子依赖,依赖的版本,获取地址与验证模块完整性的 hash。

即使是不同的安装顺序,相同的依赖关系在任何的环境和容器中,都能得到稳定的 node_modules 目录结构,保证了依赖安装的确定性。

所以 yarn 在出现时被定义为快速、安全、可靠的依赖管理。而 npm 在一年后的 v5 才发布了 package-lock.json

从我搜集到的情况来看,yarn 一开始的主要目标是解决上一节中描述的由于语义版本控制而导致的 npm 安装的不确定性问题。虽然可以使用 npm shrinkwrap 来实现可预测的依赖关系树,但它并不是默认选项,而是取决于所有的开发人员知道并且启用这个选项。

Yarn 采取了不同的做法。每个 yarn 安装都会生成一个类似于 npm-shrinkwrap.json yarn.lock 文件,而且它是默认创建的。除了常规信息之外,yarn.lock 文件还包含要安装的内容的校验和,以确保使用的库的版本相同。


pnpm logo

pnpm

pnpm(performant npm),在 2017 年正式发布,定义为快速的,节省磁盘空间的包管理工具,开创了一套新的依赖管理机制,成为了包管理的后起之秀。

内容寻址存储 CAS

与依赖提升和扁平化的 node_modules 不同,pnpm 引入了另一套依赖管理策略:内容寻址存储。

该策略会将包安装在系统的全局 store 中,依赖的每个版本只会在系统中安装一次。

在引用项目 node_modules 的依赖时,会通过硬链接与符号链接在全局 store 中找到这个文件。为了实现此过程,node_modules 下会多出 .pnpm 目录,而且是非扁平化结构。

  • 硬链接 Hard link:硬链接可以理解为源文件的副本,项目里安装的其实是副本,它使得用户可以通过路径引用查找到全局 store 中的源文件,而且这个副本根本不占任何空间。同时,pnpm 会在全局 store 里存储硬链接,不同的项目可以从全局 store 寻找到同一个依赖,大大地节省了磁盘空间。
  • 符号链接 Symbolic link:也叫软连接,可以理解为快捷方式,pnpm 可以通过它找到对应磁盘目录下的依赖地址。

还是使用上面 A,B,C 模块的示例,使用 pnpm 安装依赖后 node_modules 结构如下:

node_modules
├── .pnpm
│   ├── A@1.0.0
│   │   └── node_modules
│   │       ├── A => <store>/A@1.0.0
│   │       └── B => ../../B@1.0.0
│   ├── B@1.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@1.0.0
│   ├── B@2.0.0
│   │   └── node_modules
│   │       └── B => <store>/B@2.0.0
│   └── C@1.0.0
│       └── node_modules
│           ├── C => <store>/C@1.0.0
│           └── B => ../../B@2.0.0
│
├── A => .pnpm/A@1.0.0/node_modules/A
└── C => .pnpm/C@1.0.0/node_modules/C

<store>/xxx 开头的路径是硬链接,指向全局 store 中安装的依赖。

其余的是符号链接,指向依赖的快捷方式。

未来可期

这套全新的机制设计地十分巧妙,不仅兼容 node 的依赖解析,同时也解决了:

  1. 幽灵依赖问题:只有直接依赖会平铺在 node_modules 下,子依赖不会被提升,不会产生幽灵依赖。
  2. 依赖分身问题:相同的依赖只会在全局 store 中安装一次。项目中的都是源文件的副本,几乎不占用任何空间,没有了依赖分身。

同时,由于链接的优势,pnpm 的安装速度在大多数场景都比 npm 和 yarn 快 2 倍,节省的磁盘空间也更多。

但也存在一些弊端:

  1. 由于 pnpm 创建的 node_modules 依赖软链接,因此在不支持软链接的环境中,无法使用 pnpm,比如 Electron 应用。
  2. 因为依赖源文件是安装在 store 中,调试依赖或 patch-package 给依赖打补丁也不太方便,可能会影响其他项目。

引用

Leecason – 知乎专栏

钱曙光 – 一文看懂npm、yarn、pnpm之间的区别 – CSDN

Vue 3 兄弟组件间传值

Vue 3 中兄弟间传值可以使用 Vuex,但小项目使用过于庞大,我们可以使用 mitt 进行兄弟组件间传值。

操作步骤

第一步:安装 mitt

npm i mitt

第二步:创建文件(例如:eventBus.js

import mitt from 'mitt'

const emitter = mitt()
export default emitter

第三步:将该文件引入至需要进行发送及接受的 .vue 文件中

import emitter from "../untils/bus";

第四步:发送端写入下列代码

emitter.emit("response", response)

前面是事件,后面是要传入的参数

第五步:接收端写入下列代码

emitter.on("response", (response) => {
    console.log(response)
})

这样两个组件间就可以进行传值通信了。

Docker 下 MySQL 8 自动备份

MySQL logo

root@debian:~# crontab -e 进入crontab,添加以下内容:

0 2 * * * find /var/backup/ -mtime +5 -name "*.sql" -delete && docker exec mysql sh -c 'exec mysqldump --all-databases -u<username> -p<password> --all-databases' > /var/backup/bcksql_`date +\%F`.sql

0 2 * * *:crontab 每天 2 点

find /var/backup/ -mtime +5 -name "*.sql" -delete:查找该路径下的备份文件,删除 6 天前的备份任务,即保留 7 个版本

-u<username> -p<password>:数据库的用户名及密码

/var/backup/bcksql_`date +\%F`.sql:将备份文件保存到该路径下并命名为“bcksql_日期.sql”(以上路径需要有对应权限,否则无法正常存储)

mysqldump 常用操作示例

备份全部数据库的数据和结构

mysqldump -uroot -p123456 -A > /data/mysqlDump/mydb.sql

备份全部数据库的结构(加 -d 参数)

mysqldump -uroot -p123456 -A -d > /data/mysqlDump/mydb.sql

备份全部数据库的数据(加 -t 参数)

mysqldump -uroot -p123456 -A -t > /data/mysqlDump/mydb.sql

备份单个数据库的数据和结构(数据库名mydb)

mysqldump -uroot-p123456 mydb > /data/mysqlDump/mydb.sql

备份单个数据库的结构

mysqldump -uroot -p123456 mydb -d > /data/mysqlDump/mydb.sql

 备份单个数据库的数据

mysqldump -uroot -p123456 mydb -t > /data/mysqlDump/mydb.sql

 备份多个表的数据和结构(数据,结构的单独备份方法与上同)

mysqldump -uroot -p123456 mydb t1 t2 > /data/mysqlDump/mydb.sql

一次备份多个数据库

mysqldump -uroot -p123456 --databases db1 db2 > /data/mysqlDump/mydb.sql

Vue 3 锚点实现方式

当我们使用 Vue 3 有时候需要做业内锚点跳转,使用传统的 a href 已经不是很推荐了,我们可以尝试采用以下方法来进行替代

标题锚点

<div class="cardTagContainer">
    <div class="cardTag" v-for="(cardGroup,index) in card.cardInfo" :key="cardGroup" @click="goAnchor('#tag' + index)">
        {{ cardGroup.title }}
    </div>
</div>

跳转内容

<h1 :id="'tag' + index">
    {{ cardGroup.title }}
</h1>

相关方法

// 标题锚点
function goAnchor(selector) {
    // console.log(selector)
    document.querySelector(selector).scrollIntoView({
        behavior: "smooth",
        block: "start"
    });
}

.scrollIntoView 属性方法

scrollIntoView() 方法将调用它的元素滚动到浏览器窗口的可见区域。

PS:根据其他元素的布局,元素可能无法完全滚动到顶部或底部。

TIPS:页面(容器)可滚动时才有用!


element.scrollIntoView(); // 等同于element.scrollIntoView(true)
element.scrollIntoView(alignToTop); // 布尔参数
element.scrollIntoView(scrollIntoViewOptions); // 对象参数

Scoop 包管理工具

安装步骤

打开 PowerShell远程权限

Set-ExecutionPolicy RemoteSigned -scope CurrentUser;

若出现提示是否要更改执行策略?,输入 Y 回车

自定义 Scoop 包安装路径

$env:SCOOP='自定义路径'
[environment]::setEnvironmentVariable('SCOOP',$env:SCOOP,'User')
iwr -useb get.scoop.sh | iex

如果跳过该步骤,Scoop 将默认把所有用户安装的 App 和 Scoop 本身置于 C:\Users\\scoop

安装 Scoop

iwr -useb get.scoop.sh | iex
scoop update

或者使用国内镜像:

iwr -useb https://gitee.com/glsnames/scoop-installer/raw/master/bin/install.ps1 | iex
scoop config SCOOP_REPO 'https://gitee.com/glsnames/Scoop-Core'
scoop update

如果提示错误,说明 PowerShell 需要调整进行一些配置。这时按照提示,输入:

Set-ExecutionPolicy RemoteSigned -scope CurrentUser

然后重新运行第一条指令即可。

如果发现安装速度极慢,导致安装错误,但再次安装仍提示 scoop 已安装,那么可以输入下面这一行指令来强制删除,然后再重新安装:

del .\scoop -Force

安装 Scoop 的 bucket

安装完毕,但是我们还要再安装一个 scoop 的 bucket。scoop 默认自带的 bucket 是 main,包含大量的没有 GUI 的程序,比如 Node.js,Aria2,Git,FFmpeg 等。如果想要安装带有 GUI 的程序,可以安装名为 extras 的 bucket。

安装 extras 很简单,只需要一行指令:

scoop bucket add extras

如果出现问题,或者不想用这个 bucket 了,那么可以用下面这条语句来删除:

scoop bucket rm extras

操作命令

帮助语法

scoop help

安装操作

scoop install 软件名

安装指定Bucket中的应用

scoop install extras/sumatrapdf

安装指定版本

scoop install python@3.7.9

版本切换

scoop reset python
scoop reset python27

更新指定应用

scoop update python

禁止更新指定应用

scoop hold python

解除禁止更新指定应用

scoop unhold python

更新所有已安装应用

scoop update *

更新 bucket 库

scoop update

清理所有旧版本

scoop cleanup *

卸载操作

scoop uninstall 软件名

全局卸载(包括persist)

scoop uninstall 软件名 -p

常用软件表

01.aria2:scoop install aria2
02.everything:scoop install everything
03.cmder:scoop install cmder
04.notepad2:scoop install echo/notepad2
05.q-dir:scoop install q-dir
06.vim:scoop install vim
07.keepass:scoop install keepass
08.chrome:scoop install googlechrome
09.firefox:scoop install firefox
10.vivaldi:scoop install vivaldi
11.opera:scoop install opera
12.python:scoop install python
13.nodejs:scoop install nodejs
14.go:scoop install go
15.trafficmonitor:scoop install trafficmonitor
16.notepadplusplus:scoop install notepadplusplus
17.sublime-text:scoop install sublime-text
18.vscode:scoop install vscode
19.pycharm:scoop install pycharm
20.intellij-idea:scoop install intellij-idea
21.goland:scoop install goland
22.fscapture:scoop install echo/fscapture
23.snipaste:scoop install snipaste
24.synctrayzor:scoop install synctrayzor
25.telegram:scoop install telegram
26.notion:scoop install notion
27typora:scoop install typora

青龙任务库

KingRan/KR(集合库)

ql repo https://github.com/KingRan/KR.git "jd_|jx_|jdCookie" "activity|backUp" "^jd[^_]|USER|utils|function|sign|sendNotify|ql|JDJR"

Zy143L/wskey(wskey转换库)

ql repo https://github.com/Zy143L/wskey.git "wskey"

Yiov

ql repo https://github.com/Yiov/wool.git "" "COOKIE"

Yun-City/City(集合库)

ql repo https://github.com/Yun-City/City.git "jd_|jx_|gua_|jddj_|getJDCookie" "activity|backUp" "^jd[^_]|USER|function|utils|sendnotify|ZooFaker_Necklace|jd_Cookie|JDJRValidator_|sign_graphics_validate|ql|magic|cleancart_activity"

gys619/Absinthe(集合库)

ql repo https://github.com/gys619/Absinthe.git "jd_|jx_|jddj_|gua_|getJDCookie|wskey" "activity|backUp" "^jd[^_]|USER|utils|ZooFaker_Necklace|JDJRValidator_|sign_graphics_validate|jddj_cookie|function|ql|magic|JDJR|JD" "main"

zero205/JD_tencent_scf

ql repo https://github.com/zero205/JD_tencent_scf.git "jd_|jx_|jdCookie" "backUp|icon" "^jd[^_]|USER|sendNotify|sign_graphics_validate|JDJR|JDSign|ql" "main"

6dylan6/jdpro(集合库)

ql repo https://github.com/6dylan6/jdpro.git "jd_|jx_|jddj_" "backUp" "^jd[^_]|USER|JD|function|sendNotify"

smiek2121(开卡库)

ql repo ql repo https://github.com/smiek2121/scripts.git "jd_|gua_" "" "ZooFaker_Necklace.js|JDJRValidator_Pure.js|sign_graphics_validate.js|cleancart_activity.js|jdCookie.js|sendNotify.js"

Docker 部署青龙面板

部署青龙面板

docker pull qinglong

在相关目录创建 docker-compose.yml

mkdir ql
cd ql
touch docker-compose.yml

然后输入 vi docker-compose.yml 并填写以下内容

version: "3"
services:
  qinglong:
    image: whyour/qinglong:latest
    container_name: qinglong
    restart: unless-stopped
    tty: true
    ports:
      - 5700:5700
      - 5701:5701
    environment:
      - ENABLE_HANGUP=true
      - ENABLE_WEB_PANEL=true
    volumes:
      - ./config:/ql/config
      - ./log:/ql/log
      - ./db:/ql/db
      - ./repo:/ql/repo
      - ./raw:/ql/raw
      - ./scripts:/ql/scripts
      - ./jbot:/ql/jbot
      - ./ninja:/ql/ninja
      - ./damei:/ql/damei
    labels:
      - com.centurylinklabs.watchtower.enable=false

保存后退出,在窗口输入:

docker-compose up -d

等待下载完成

下载完成后提示 Creating qinglong *** done并返回root输入提示

Docker 常用命令

Docker logo

Docker 安装

curl -sSL https://get.daocloud.io/docker | sh

Docker-Compose 安装并设置权限

curl -L https://get.daocloud.io/docker/compose/releases/download/v2.3.3/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

配置 Docker 镜像源

创建 daemon.json 文件

sudo mkdir -p /etc/docker

写入镜像源

sudo tee /etc/docker/daemon.json
{
  "registry-mirrors": ["http://hub-mirror.c.163.com","https://docker.mirrors.ustc.edu.cn","https://registry.docker-cn.com"]
}

赋予普通用户执行 Docker 命令

gpasswd -a username docker

Docker 使用

搜索镜像

docker search debian

拉取镜像

docker pull debian

查看镜像文件

docker images

查看镜像层级关系

docker images tree

查看 Docker 所有进程

docker ps -a

查看 Docker 内存占用

docker stats

开启容器

docker start debian

开启所有容器

docker start $(docker ps -aq)

进入正在运行中的容器

docker exec -it debian /bin/bash

重启容器

docker restart 容器 ID

文件传输

docker cp 本地文件路径 ID全称:容器路径
或
docker cp ID全称:容器文件路径 本地路径

卸载

停止容器

docker stop debian

停止所有容器

docker stop $(docker ps -aq)

删除指定容器

docker rm 容器 ID

删除所有已停止容器

docker rm $(docker ps -aq)

删除所有镜像

docker rmi 镜像 ID

Linux init 详解

什么是 init

init 进程是一个由内核启动的用户级进程

内核自行启动(已经被载入内存,开始运行,并已初始化所有的设备驱动程序和数据结构等)之后,就通过启动一个用户级程序 init 的方式,完成引导进程。所以,init 始终是第一个进程(其进程编号始终为1)。

内核会在过去曾使用过init的几个地方查找它,它的正确位置(对 Linux 系统来说)是 /sbin/init 。如果内核找不到 init,它就会试着运行 /bin/sh ,如果运行失败,系统的启动也会失败。

运行级别

init 一共分为 7 个级别,这 7 个级别的所代表的含义如下:

#init 0 - 停机(千万不能把initdefault 设置为 0)
#init 1 - 单用户模式,只由 root 用户进行维护
#init 2 - 多用户,不能使用NFS(Net File System)不联网
#init 3 - 完全多用户模式(标准的运行级)
#init 4 - 安全模式
#init 5 - X11 (xwindow) 图形化界面模式
#init 6 - 重新启动 (千万不要把 initdefault 设置为6 )

开机默认模式设置方法

系统下有个根文件目录:/etc/inittab

.  # inittab       This file describes how the INIT process should set up
.  #               the system in a certain run-level.
.  #
.  # Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
.  #               Modified for RHS Linux by Marc Ewing and Donnie Barnes
.  #
.  # Default runlevel. The runlevels used by RHS are:
.  #   0 - halt (Do NOT set initdefault to this)
.  #   1 - Single user mode
.  #   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
.  #   3 - Full multiuser mode
.  #   4 - unused
.  #   5 - X11
.  #   6 - reboot (Do NOT set initdefault to this)
.  #
.  id:3:initdefault:

如果设置为 id:3:initdefault: 这代表默认启动为命令行模式。如果设置为 id:5:initdefault: 这代表默认 xwindow 图形化界面模式

Debian 系没有 /etc/inittab 文件

使用命令实现,使用 apt install sysv-rc-conf 安装

然后再次执行命令运行:sysv-rc-conf

如何查看当前运行级别

使用 runlevel 命令查看

root@debian:~# runlevel
N 5