1. 数据分析

1.1 均值还是90分位数

看均值的场景:

1. 数据分布较为正态或对称时
2. 数据波动不大,没有明显的异常值
3. 需要了解整体水平或趋势
4. 样本量较大且分布均匀

看90分位数的场景:

1. 数据分布倾斜时
2. 需要排除异常值影响时
3. 长尾分布（少数爆款视频点击量高，大量普通视频点击量低）

1. AWS 基础

1.1 使用场景

安装 awscli

1
2

brew install awscli
aws configure  # 配置下aws configure

获取 access_key_id

1. 登录 AWS 管理控制台
2. 点击右上角的账户名称，选择 “Security credentials” (安全凭证)
3. 在安全凭证页面，找到 “Access keys” (访问密钥) 部分
4. 点击 “Create New Access Key” (创建新的访问密钥)

我们通常说的 “ 苹果支付 IAP” 其实是指 In-App Purchase (IAP)，即 “ 应用内购买 “。而 Apple Pay 是苹果的支付工具，可以在 App、网页或实体店里用来付款，两者是不同的体系。我们这里主要讨论 IAP。

客户端只负责 “ 请求购买 “ 和 “ 展示商品 “，而 “ 校验票据 “ 和 “ 发放商品 “ 的权威必须是你的服务器。

1. 区别

1.1 多阶段构建

你可以在一个 Dockerfile 中定义多个构建阶段。例如，一个阶段用来编译代码（包含所有开发依赖），另一个阶段只把编译好的产物复制到一个干净的基础镜像中。

1. 使用

1.1 破解(20250714)

池子：https://poolhub.me/

mac 换号：https://github.com/J3n5en/curs0r-release

Flux 模型是一种全新的、革命性的文生图（text-to-image）模型架构。它不是 Stable Diffusion 的一个新版本或微调（checkpoint），而是一个从根本上设计就不同的系统。它的核心优势是极快的生成速度和极其出色的提示词理解能力。

什么是任务队列 ?

消息队列（Message Queue），一般来说知道的人不少。比如常见的：kafka、Rabbitmq、RocketMQ 等。

任务队列（Task Queue），听说过这个概念的人不会太多，清楚它的概念的人怕是更少。

这两个概念是有关系的，他们是怎样的关系呢？任务队列（Task Queue）是消息队列（Message Queue）的超集。任务队列是构建在消息队列之上的。消息队列是任务队列的一部分。

1. 规范

1.1 基本的 commit 信息格式

一个常见的提交信息格式通常包括以下几个部分：

• 类型（type）: 描述提交的类别，比如是新功能、修复、文档等。
• 范围（scope）: 可选，描述提交影响的范围，比如是某个模块、功能等。
• 主题（subject）: 简短的描述提交的目的。
• 正文（body）: 可选，详细描述提交的内容、动机等。
• 页脚（footer）: 可选，通常用于关闭某个 issue 或者添加破坏性变更的说明。

1. builtin

1.1 clear (go1.21.0)

对于map，清除删除所有条目，导致map为空。对于slice，清除将所有直到slice长度的元素设置为相应元素类型的零值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package main

import "fmt"

func main() {
	m := map[string]string{
		"1": "2",
		"2": "2",
		"3": "2",
	}
	fmt.Println(m, len(m))
	clear(m)
	fmt.Println(m, len(m))

	s := []string{"1", "2", "3"}
	fmt.Println(s, len(s))
	clear(s)
	fmt.Println(s, len(s), len(s[0]))
}

/*
map[1:2 2:2 3:2] 3
map[] 0
[1 2 3] 3
[  ] 3 0
*/

Rust 是一门现代的、开源的系统编程语言，其设计的核心目标是同时实现安全（Safety）、并发（Concurrency）和性能（Performance）。它通过在编译时强制执行一系列严格的规则，来消除一整类常见的内存错误（如空指针、悬垂指针、数据竞争等），而无需像 Java 或 Go 那样依赖垃圾回收器（Garbage Collector）。

Rust 就像一位拥有 “ 魔法钥匙 “ 的贴身管家：任何时候，一件珍贵的物品（一块内存数据）要么只能由一个人持有 “ 主钥匙 “（可写入权限），要么可以被多个人持有 “ 复制钥匙 “（只读权限），但绝不允许 “ 主钥匙 “ 和任何 “ 复制钥匙 “ 同时存在。这位管家（编译器）在你的程序 “ 运行 “ 之前，就会严格检查所有钥匙的分配，确保万无一失。