256G 的 MacBook Pro 用了2年了，最近发现磁盘空间越来越小，每次重启后还能剩余 20G 的空间，用一天后就开始硬盘余额告急，能清理的都清理了，还是不够用。实在找不到能够清理的内容了。
但是“其他”选项占用了大部分磁盘空间，可以这该清理什么内容呢？
可以尝试在命令行执行以下命令：
查看具体文件夹信息
du -sh <folder>
找到大文件，可以尝试删除。
rm -rf <file>
比如查看~/Library/Caches目录
$ du -h -d 1 | sort -h
会输出当前目录下所有子文件夹的大小，根据实际情况来清理。
一顿深度清理后，磁盘空间腾出40G来，总算能再撑一段时间了。
使用电脑的人免不了使用浏览器，电脑端浏览器的一大特色是插件和扩展，等于是给浏览器添加外挂，增加一些额外的有用功能，比如：
我自己使用的一些插件具备以下功能：
等等…… 然而，手机端的浏览器基本不支持插件功能。 但是令我万万没有想到的是，苹果手机的浏览器居然已经支持扩展功能了。
目前支持的扩展数量还有限，但是也算有个好的开头，也有一些比较使用的扩展。
虽然很多文章说不建议将数据库部署在容器中，因为有性能问题。但我觉得这事还是要看具体使用场景来决定，而不是全盘否定。开发的过程中并不只有性能是最重要的，还有效率，易用性等也很重要。
对于测试环境来说，数据库部署在容器中肯定是可以的。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: mysql
name: mysql
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: mysql
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
labels:
app: mysql
spec:
containers:
- env:
- name: MYSQL_ROOT_PASSWORD
value: xxx
image: mysql:8.0.33
imagePullPolicy: IfNotPresent
name: mysql
ports:
- containerPort: 3306
name: mysql
protocol: TCP
resources:
limits:
cpu: "4"
memory: 8Gi
volumeMounts:
- mountPath: /var/lib/mysql
name: data
- mountPath: /etc/mysql/conf.d/
name: mysql-config
volumes:
- name: data
persistentVolumeClaim:
claimName: mysql
- configMap:
defaultMode: 420
name: mysql-config
name: mysql-config
---
apiVersion: v1
kind: ConfigMap
data:
my.cnf: |-
[client]
default-character-set = utf8mb4
[mysql]
default-character-set=utf8mb4
[mysqld]
character-set-server=utf8mb4
collation_server=utf8mb4_unicode_ci
gtid_mode=ON
enforce_gtid_consistency=ON
lower_case_table_names=1
open_files_limit=65535
slow_query_log = ON
long_query_time = 2
max_heap_table_size = 32M
tmp_table_size = 2M
log-bin = mysql-bin
binlog_cache_size = 32K
max_binlog_cache_size = 1G
max_binlog_size = 1G
binlog-format = ROW
sync_binlog = 1
log-slave-updates = 1
expire_logs_days = 7
default-time_zone = +8:00
max_connect_errors = 65535
max_allowed_packet = 536870912
max_connections = 5120
innodb_buffer_pool_instances = 1
innodb_buffer_pool_size = 6442450944
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:15G
server_id = 100
metadata:
name: mysql-config
数据安全一直是企业安全的重中之重，在企业系统开发过程中，数据库的安全日益增强，所以需要有个平台能够记录和审查数据库变更。
SQL 审计平台的功能特点：
常见的sql审计平台：
开发语言：golang
功能：
支持容器部署。
开发语言：python
功能：
| 查询 | 审核 | 执行 | 备份 | 数据字典 | 慢日志 | 会话管理 | 账号管理 | 参数管理 | 数据归档 |
|---|---|---|---|---|---|---|---|---|---|
| MySQL | √ | √ | √ | √ | √ | √ | √ | √ | √ |
| MsSQL | √ | × | √ | × | × | × | × | × | × |
| Redis | √ | × | √ | × | × | × | × | × | × |
| PgSQL | √ | × | √ | × | × | × | × | × | × |
| Oracle | √ | √ | √ | √ | × | × | × | × | × |
| MongoDB | √ | √ | √ | × | × | × | × | × | × |
| Phoenix | √ | × | √ | × | × | × | × | × | × |
| ODPS | √ | × | × | × | × | × | × | × | × |
| ClickHouse | √ | × | × | × | × | × | × | × | × |
基于Inception/goInception实现，集成审核、执行、备份
多年前微信开发写过一篇关于内网穿透的文章《微信开发通过公网访问本地服务器》，随着时间的推移，有些方法已经不再适用。
前面提到的公网访问本地服务器还是有一些限制，那时候是基于路由器的内网映射实现的，不是所有路由器都具备内网映射功能，就像我现在使用的路由器是移动宽带送的，外面看着挺有内涵，实际功能少的可怜。还是需要通过其他方式实现内网穿透。
不可用的方式——ngrok
最开始想通过ngrok来实现，结果发现怎么都无法通过token验证，原因是ngrok会在首次打开时展现广告页面。
可用的方式——借助花生壳来实现
如果通过客户端无法选择htt和http协议，提示：“不支持web访问方式，如有需要请使用HTTP或HTTPS”，就去web页面配置即可 -> https://console.hsk.oray.com/forward
此处的服务器地址(URL) 不止用于验证token，如果在文档中看到这样的字样，就是指这个地址，比如它还可以用于接收各种消息。这个地址是生产服务器地址，如果是开发阶段也不用将开发服务器地址配置到这里，因为微信提供了专门用于测试的配置，往下看。
测试号管理点开后就会看到和上面服务器配置一样的配置内容。
测试账号具备所有API权限，所以你不用为了测试接口而花300元认证，而且认证也不对个人开放。
设置路径：设置与开发 -> 安全中心 -> IP白名单
这个IP是通过ping内网穿透得到的IP，不是你电脑的内网IP，也不是你的电脑公网IP。有可能会变如果接口突然访问不同请检测是否IP已变动。
有了以上准备基本就可以正式进入开发阶段了。祝一切顺利！
生成crt证书
openssl req -new -x509 -key domain.key -out domain.crt -days 365
将CRT转换为CSR：
openssl req -new -key domain.key -out domain.csr
针对OSS内存储的图片文件（Object），您可以在GetObject请求中携带图片处理参数对图片文件进行处理。例如添加图片水印、转换格式等。详情见：官方文档
对于允许公共读写的文件可以直接在图片URL后面拼接参数的方式进行图片处理，格式：https://bucketname.endpoint/objectname?x-oss-process=image/action,parame_value
对于不允许匿名访问的私有图片文件，不支持通过文件URL直接添加参数的方式处理图片，您需要通过SDK的方式将图片处理操作加入签名URL中。
重要： 通过文件URL访问图片时，默认是下载行为。如需确保通过文件URL访问图片时是预览行为，您需要绑定自定义域名并添加CNAME记录。具体操作，请参见绑定自定义域名。
所以，私有桶的图片是不能直接添加参数处理，否则会返回错误信息：
SignatureDoesNotMatch
The request signature we calculated does not match the signature you provided. Check your key and signing method.
SDK处理方法，以go版本为例：
package main
import (
"fmt"
"os"
"github.com/aliyun/aliyun-oss-go-sdk/oss"
)
func HandleError(err error) {
fmt.Println("Error:", err)
os.Exit(-1)
}
func main() {
// 创建OSSClient实例。
// yourEndpoint填写Bucket对应的Endpoint，以华东1（杭州）为例，填写为https://oss-cn-hangzhou.aliyuncs.com。其它Region请按实际情况填写。
// 阿里云账号AccessKey拥有所有API的访问权限，风险很高。强烈建议您创建并使用RAM用户进行API访问或日常运维，请登录RAM控制台创建RAM用户。
client, err := oss.New("yourEndpoint", "yourAccessKeyId", "yourAccessKeySecret")
if err != nil {
HandleError(err)
}
// 指定图片所在Bucket的名称，例如examplebucket。
bucketName := "examplebucket"
bucket, err := client.Bucket(bucketName)
if err != nil {
HandleError(err)
}
// 指定图片名称。如果图片不在Bucket根目录，需携带文件完整路径，例如exampledir/example.jpg。
ossImageName := "exampledir/example.jpg"
// 生成带签名的URL，并指定过期时间为600s。
signedURL, err := bucket.SignURL(ossImageName, oss.HTTPGet, 600, oss.Process("image/format,png"))
if err != nil {
HandleError(err)
} else {
fmt.Println(signedURL)
}
}
其中，yourAccessKeyId,yourAccessKeySecret的来源参考该文，阿里云OSS上传报错: You have no right to access this object because of bucket acl。创建完用户需要创建AccessKeyId，接着就可以创建yourAccessKeyId和AccessKeySecret。
最后会生成完整的图片链接，注意，如果发现链接中多出了bucket，需要排查yourEndpoint是否已经加上了bucket，需要删除掉。
谁能想到，一个前端组件也能把服务搞崩溃。这个组件正是next/image，原本是想利用next/image来优化图片，next.js官方也一直推荐这么做。
突然有一天用户反馈网站出现504超时报错，当时优先重启恢复服务。然后把日志打开观察，果不其然，几分钟后就又出现504超时，伴随出现的日志则是：
upstream image response failed for https://example.com/280d59d8-f3b0-11ed-a295-00163e253f9a_00002_VvBbv3zj.jpg?OSSAccessKeyId=LTAI5nodLHeacT1J5SmWh&Expires=317044217325&Signature=Wf5jYWf7vnXOyRoKLVtiTCrt8%3D 404
初步判断是图片404导致服务器超时，深入猜测是使用next.js服务端渲染请求了图片资源，而图片资源不存在导致服务器渲染出错。
但是很不合理，服务端只是把图片资源的地址渲染到html中，并不会在服务端请求图片资源才对，为什么服务器日志会出现上述错误信息呢？于是观察浏览器中图片的请求，发现格式是这样的：
http://example.com/_next/image?url=https%3A%2F%2Fexample.com%2Ff6c912da-f0cc0000_0d7GBaLE.jpg%3FOSSAccessKeyId%3DmWh%26Expires%3D317043899846%26Signature%3DYUMro%253D&w=384&q=75
浏览器请求的图片资源并不是图片的真实地址，而是经过了next.js服务处理的，尤其是URL最后两个参数，是图片压缩参数。如果你发现图片变模糊了，也可能是这两个参数捣的鬼。直接拿着这个地址去浏览器请求发现响应很慢，这时再次得出结论：这个图片组件有问题。为了验证把所有使用了next/image组件全部使用原生img标签，发布到线上后就再没出现504超时。
总结：next/image组件包装后的图片资源需要经过node层压缩处理，会消耗CPU资源，对于大量的图片资源会有风险，酌情处理。
本次出现的时候伴随着图片资源404，可能是有bug存在，如果加载不到正确的图片就会触发bug。
另一种解决方案：根据官方文档说明，如果使用next/image,需要添加sharp包来提高性能，但是可能需要注意内存消耗问题。
为了使next.js项目能够不宕机，使用了pm2守护进程，既能保证node出现异常情况能够自动重启，也能保证服务器整机重启时自动恢复服务。多年使用下来的确能够良好运行，不过最近却出现了与原本期望不符的情况。
在已经启动next.js项目的情况下，如果需要重启，我使用了pm2 reload appname，实际上没有完美的零停机重启，反而是直接出现服务不可用，访问网站就502，并且一直无法恢复。在查阅pm2 issue后发现确实有这样的bug。
无奈，只能使用pm2 restart来重启应用。
如果你打算搭建一套发布系统，你可能会考虑jenkins，或者其他。 我要介绍的则是一些现成的，使用更简单的工具。没用特殊环境要求的情况下则完全可以代替jenkins。
上面只是列举了四类，实际上你会发现市面上的云服务商和代码仓库都提供了类似的工具，虽然有些是收费的，但是也有不少免费的，对于个人来说其实大多数都是够用了。