用户6004295327968
获得徽章 3
赞了这篇文章
赞了这篇文章
#青训营 x 字节后端训练营# 出现 "Uncaught (in promise) SyntaxError: Unexpected end of JSON input" 错误提示，通常表示接收到了空的JSON字符串。这种情况很可能是由于服务器端返回的响应数据为空引起的。
针对这个问题，你需要在使用 JSON.parse 方法对服务器返回的数据进行解析之前，先判断一下数据是否为空，以避免解析错误。代码修改如下：
fetch('food/order', { order_id: options.order_id}).then((res) => {
if(res.data) { // 判断数据是否为空
var foods = JSON.parse(res.data);
// ...其他代码
} else {
console.error("接收到空数据");
}
}).catch((error) => {
console.error(error);
});
在上述代码中，我们添加了条件判断，当服务器返回的数据为空时，打印一个错误日志到控制台。这样可以更清晰地了解到发生了什么，并将问题及时报告给开发人员
针对这个问题，你需要在使用 JSON.parse 方法对服务器返回的数据进行解析之前，先判断一下数据是否为空，以避免解析错误。代码修改如下：
fetch('food/order', { order_id: options.order_id}).then((res) => {
if(res.data) { // 判断数据是否为空
var foods = JSON.parse(res.data);
// ...其他代码
} else {
console.error("接收到空数据");
}
}).catch((error) => {
console.error(error);
});
在上述代码中，我们添加了条件判断，当服务器返回的数据为空时，打印一个错误日志到控制台。这样可以更清晰地了解到发生了什么，并将问题及时报告给开发人员
展开
评论
点赞
#青训营 x 字节后端训练营# module.exports = function(path, data, method) {
return new Promise((resolve, reject) => {
wx.request({
url: '', // 接口地址
method: method,
data: data,
header: {'Content-Type': 'json' },
success: function(res) { // 请求成功执行resolve操作
resolve(res.data);
},
fail: function() { // 请求失败执行fail操作
reject()
wx.showModal({ showCancel: false, title: '失败' })
}
})
})
}
在请求成功后，调用 resolve 函数并传入响应数据，Promise 的状态会变为已解决（fulfilled），并将响应数据传递给下一个 then 函数。
return new Promise((resolve, reject) => {
wx.request({
url: '', // 接口地址
method: method,
data: data,
header: {'Content-Type': 'json' },
success: function(res) { // 请求成功执行resolve操作
resolve(res.data);
},
fail: function() { // 请求失败执行fail操作
reject()
wx.showModal({ showCancel: false, title: '失败' })
}
})
})
}
在请求成功后，调用 resolve 函数并传入响应数据，Promise 的状态会变为已解决（fulfilled），并将响应数据传递给下一个 then 函数。
展开
评论
点赞
#青训营 x 字节后端训练营# 在 Git 中，每个提交都有一个唯一的 SHA-1 标识符，表示该提交的内容和元数据。提交历史是由一系列提交组成的，每个提交都有一个父提交，除了第一个提交（也称为根提交）之外，它没有父提交。
当我们使用 Rebase 方式将传入的更改变基到当前分支时，Git 会首先找到当前分支和传入的更改之间的最近公共祖先（common ancestor），然后将当前分支的更改按照时间顺序依次应用到传入的更改之后。这个过程中，Git 会创建新的提交，代表每个应用的更改。
由于 Rebase 方式是按照时间顺序依次应用更改，因此提交历史会变得更加线性。具体来说，如果我们使用 Merge 方式将传入的更改合并到当前分支，会形成一个新的合并提交，该提交有两个父提交，分别代表当前分支和传入的更改。而如果我们使用 Rebase 方式将传入的更改变基到当前分支，会形成一系列新的提交，每个提交只有一个父提交，代表当前分支的更改。
这种线性的提交历史有一些优点。首先，它更加清晰和易于理解，可以更好地反映代码的演化过程。其次，它可以减少合并冲突的可能性，因为每个提交只涉及一个分支的更改。
需要注意的是，在使用 Rebase 方式时，由于会修改提交历史，可能会对其他人的工作造成影响，因此需要谨慎使用，并在必要时与其他人进行协调。
当我们使用 Rebase 方式将传入的更改变基到当前分支时，Git 会首先找到当前分支和传入的更改之间的最近公共祖先（common ancestor），然后将当前分支的更改按照时间顺序依次应用到传入的更改之后。这个过程中，Git 会创建新的提交，代表每个应用的更改。
由于 Rebase 方式是按照时间顺序依次应用更改，因此提交历史会变得更加线性。具体来说，如果我们使用 Merge 方式将传入的更改合并到当前分支，会形成一个新的合并提交，该提交有两个父提交，分别代表当前分支和传入的更改。而如果我们使用 Rebase 方式将传入的更改变基到当前分支，会形成一系列新的提交，每个提交只有一个父提交，代表当前分支的更改。
这种线性的提交历史有一些优点。首先，它更加清晰和易于理解，可以更好地反映代码的演化过程。其次，它可以减少合并冲突的可能性，因为每个提交只涉及一个分支的更改。
需要注意的是，在使用 Rebase 方式时，由于会修改提交历史，可能会对其他人的工作造成影响，因此需要谨慎使用，并在必要时与其他人进行协调。
展开
评论
点赞
#青训营 x 字节后端训练营# 将传入的更改合并到当前分支（Merge）和将传入的更改变基到当前分支（Rebase）是两种不同的代码合并方式。
在 Merge 方式中，Git 会将传入的更改和当前分支的更改合并在一起，形成一个新的合并提交。这种方式适用于多个人在同一个分支上进行开发，各自提交了自己的更改，需要将这些更改合并在一起。
在 Rebase 方式中，Git 会将当前分支的更改放在传入的更改之后，形成一个新的提交历史。这种方式适用于单个人在本地分支上进行开发，想要将自己的更改应用到远程分支上，同时保持提交历史的整洁。
区别主要体现在提交历史的变化和代码冲突的处理上。在 Merge 方式中，由于是形成一个新的合并提交，因此提交历史会出现分叉。而在 Rebase 方式中，由于是将当前分支的更改放在传入的更改之后，因此提交历史会变得更加线性。此外，在代码冲突的处理上，Merge 方式需要解决合并冲突，而 Rebase 方式需要解决变基冲突。
需要注意的是，无论是 Merge 方式还是 Rebase 方式，都需要谨慎操作，避免不必要的代码冲突和提交历史的混乱。
在 Merge 方式中，Git 会将传入的更改和当前分支的更改合并在一起，形成一个新的合并提交。这种方式适用于多个人在同一个分支上进行开发，各自提交了自己的更改，需要将这些更改合并在一起。
在 Rebase 方式中，Git 会将当前分支的更改放在传入的更改之后，形成一个新的提交历史。这种方式适用于单个人在本地分支上进行开发，想要将自己的更改应用到远程分支上，同时保持提交历史的整洁。
区别主要体现在提交历史的变化和代码冲突的处理上。在 Merge 方式中，由于是形成一个新的合并提交，因此提交历史会出现分叉。而在 Rebase 方式中，由于是将当前分支的更改放在传入的更改之后，因此提交历史会变得更加线性。此外，在代码冲突的处理上，Merge 方式需要解决合并冲突，而 Rebase 方式需要解决变基冲突。
需要注意的是，无论是 Merge 方式还是 Rebase 方式，都需要谨慎操作，避免不必要的代码冲突和提交历史的混乱。
展开
评论
点赞
#青训营 x 字节后端训练营# “堡垒主机”（英文为 bastion host），是指位于公网与内网之间的一台服务器，其主要作用是提供安全的入口，防止攻击者直接进入内网。堡垒主机具有很高的安全性，通常会使用双因素认证、防火墙、安全审计等信息安全技术来保障其安全性。除了作为安全入口，堡垒主机还可以提供一定程度的审计功能，记录管理员和普通用户的操作记录。
“蜜罐”（英文为 honeypot），是一种安全机制，它是部署在网络上的一台虚拟主机，被设计得十分脆弱，看上去非常具有诱惑力，吸引攻击者来攻击。实际上，攻击者在攻击蜜罐后并不会获得什么实际收益。攻击蜜罐可以有效地识别攻击者并记录攻击行为，帮助安全人员快速发现和识别攻击者的策略、技术和手段，以加强安全防御。
“自主访问控制”（英文为 discretionary access control，简写为 DAC）是指一种权限控制模型，由资源访问对象的所有者或管理员来定义和控制资源的访问权限。这种访问控制模型让资源的控制权和访问权限的决策权由管理员或资源所有者自行掌握，因此称为“自主访问控制”。在该模型下，管理员或资源所有者可以对资源的读、写、执行、删除等操作进行授权或限制，控制资源的访问和使用权限。
“强制访问控制”（英文为 Mandatory Access Control，简称 MAC）是另一种权限控制模型，其核心思想是为资源提供一个全局、强制性的安全政策。这种安全政策是由系统管理员或安全政策制定人员来制定的，并由系统强制执行。在该模型下，用户不能随意控制资源的访问权限，资源的访问权限受到强制访问控制规则的限制，只有经过访问控制规则检验的用户才能够访问资源。强制访问控制模型通常用于高安全性需求的场景，如军事、政府等机构的信息系统。
“蜜罐”（英文为 honeypot），是一种安全机制，它是部署在网络上的一台虚拟主机，被设计得十分脆弱，看上去非常具有诱惑力，吸引攻击者来攻击。实际上，攻击者在攻击蜜罐后并不会获得什么实际收益。攻击蜜罐可以有效地识别攻击者并记录攻击行为，帮助安全人员快速发现和识别攻击者的策略、技术和手段，以加强安全防御。
“自主访问控制”（英文为 discretionary access control，简写为 DAC）是指一种权限控制模型，由资源访问对象的所有者或管理员来定义和控制资源的访问权限。这种访问控制模型让资源的控制权和访问权限的决策权由管理员或资源所有者自行掌握，因此称为“自主访问控制”。在该模型下，管理员或资源所有者可以对资源的读、写、执行、删除等操作进行授权或限制，控制资源的访问和使用权限。
“强制访问控制”（英文为 Mandatory Access Control，简称 MAC）是另一种权限控制模型，其核心思想是为资源提供一个全局、强制性的安全政策。这种安全政策是由系统管理员或安全政策制定人员来制定的，并由系统强制执行。在该模型下，用户不能随意控制资源的访问权限，资源的访问权限受到强制访问控制规则的限制，只有经过访问控制规则检验的用户才能够访问资源。强制访问控制模型通常用于高安全性需求的场景，如军事、政府等机构的信息系统。
展开
评论
点赞
#青训营 x 字节后端训练营# 1、ConfigurableApplicationContext：接口，定义了配置与生命周期相关操作，如refresh
2、AbstractApplicationContext: 抽象类，实现了refresh方法，refresh方法作为Spring核心中的核心,可以说整个Spring皆在refresh之中，所有子类都通过refresh方法启动，在调用该方法之后，将实例化所有单例
3、AnnotationConfigApplicationContext: 在启动时使用相关的注解读取器与扫描器，往Spring容器中注册需要用的处理器，而后在refresh方法在被主流程调用即可
4、AnnotationConfigWebApplicationContext：实现loadBeanDefinitions方法，以期在refresh流程中被调用，从而加载BeanDefintion
5、ClassPathXmlApplicationContext: 同上
2、AbstractApplicationContext: 抽象类，实现了refresh方法，refresh方法作为Spring核心中的核心,可以说整个Spring皆在refresh之中，所有子类都通过refresh方法启动，在调用该方法之后，将实例化所有单例
3、AnnotationConfigApplicationContext: 在启动时使用相关的注解读取器与扫描器，往Spring容器中注册需要用的处理器，而后在refresh方法在被主流程调用即可
4、AnnotationConfigWebApplicationContext：实现loadBeanDefinitions方法，以期在refresh流程中被调用，从而加载BeanDefintion
5、ClassPathXmlApplicationContext: 同上
展开
评论
点赞
#青训营 x 字节后端训练营# Mono 是 Reactor 库中的一个类，它代表了一个包含 0 或 1 个元素的异步序列。在响应式编程中，我们通常使用 Mono 来表示一个异步操作的结果，例如从数据库中获取数据、调用远程服务等。当操作成功时，Mono 会产生一个元素，并通知订阅者；当操作失败时，Mono 会产生一个错误，并通知订阅者。
使用 Mono 对象可以实现非阻塞的异步编程模型，避免了线程的阻塞和等待，提高了系统的并发性能和吞吐量。在 Spring WebFlux 中，我们通常使用 Mono 对象来处理 HTTP 请求和响应，例如从请求中读取数据、处理业务逻辑、生成响应结果等。
使用 Mono 对象可以实现非阻塞的异步编程模型，避免了线程的阻塞和等待，提高了系统的并发性能和吞吐量。在 Spring WebFlux 中，我们通常使用 Mono 对象来处理 HTTP 请求和响应，例如从请求中读取数据、处理业务逻辑、生成响应结果等。
展开
评论
点赞
#青训营 x 字节后端训练营# 一个简单的索引方案
回到正题，我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以 不得不 依次遍历所有的数据页。所以如果我们想快速的定位到需要查找的记录在哪些数据页中该咋办？还记得我们为根据主键值快速定位一条记录在页中的位置而设立的页目录么？我们也可以想办法为快速定位记录所在的数据页而建立一个别的目录，建这个目录必须完成下边这些事儿：
下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。
回到正题，我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以 不得不 依次遍历所有的数据页。所以如果我们想快速的定位到需要查找的记录在哪些数据页中该咋办？还记得我们为根据主键值快速定位一条记录在页中的位置而设立的页目录么？我们也可以想办法为快速定位记录所在的数据页而建立一个别的目录，建这个目录必须完成下边这些事儿：
下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。
展开
评论
点赞
#青训营 x 字节后端训练营# 研发时，服务端同学开通接口，自动拉取服务，接入到网关后台；业务同学可以生成各个客户端的 RPC 代码，发给客户端同学做集成；客户端同学依靠 RPC 代码发到网关，由网关转发到业务服务器。整个过程非常简单，整体研发效率有很大的提升。
评论
点赞
#青训营 x 字节后端训练营# React由于架构机制决定了每当状态发生改变，从当前组件开始一直到叶子组件重新加载。
Vue由于给每个组件建立了watchEffect监听机制，每当组件依赖的状态发生改变，当前组件重新加载。
SolidJS和Svelte由于在编译之后就确定了当状态发生改变UI随之变化的关系，所以仅仅是具体DOM的重新加载。
Vue由于给每个组件建立了watchEffect监听机制，每当组件依赖的状态发生改变，当前组件重新加载。
SolidJS和Svelte由于在编译之后就确定了当状态发生改变UI随之变化的关系，所以仅仅是具体DOM的重新加载。
展开
评论
点赞
#青训营 x 字节后端训练营# 每个索引都对应一棵B+树，B+树分为好多层，最下边一层是叶子节点，其余的是内节点。
InnoDB存储引擎会自动为主键建立聚簇索引，聚簇索引的叶子节点包含完整的用户记录
InnoDB存储引擎会自动为主键建立聚簇索引，聚簇索引的叶子节点包含完整的用户记录
评论
点赞
#青训营 x 字节后端训练营# 执行Limit查询是，MySQL只在server层对语句进行检查，意味着查询后才会检查limit语句，对于符合条件的予以保留。对于limit5000，1语句 ，返回符合条件的第5001条数据，如果使用二级索引进行查询 那么会进行5001次回表，影响查询性能。
评论
点赞
#青训营 x 字节后端训练营# Ribbon是一个基于HTTP和TCP客户端的负载均衡器。Feign中也使用Ribbon，后续会介绍Feign的使用。
Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。
当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。
下面我们通过实例看看如何使用Ribbon来调用服务，并实现客户端的均衡负载。
Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。
当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。
下面我们通过实例看看如何使用Ribbon来调用服务，并实现客户端的均衡负载。
展开
评论
点赞