针对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.
谁能想到，一个前端组件也能把服务搞崩溃。这个组件正是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。
GitHub Actions gitlab ci 阿里云流水线 coding持续部署 上面只是列举了四类，实际上你会发现市面上的云服务商和代码仓库都提供了类似的工具，虽然有些是收费的，但是也有不少免费的，对于个人来说其实大多数都是够用了。
[root@hecs-221218 network-scripts]# yum install rsync CentOS-8 - AppStream 3.4 kB/s | 394 B 00:00 Errors during downloading metadata for repository 'AppStream': - Status code: 404 for https://repo.huaweicloud.com/centos/8/AppStream/x86_64/os/repodata/repomd.xml (IP: 61.172.228.200) Error: Failed to download metadata for repo 'AppStream': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried 解决办法：
修改/etc/yum.repos.d/CentOS-AppStream.repo中的baseurl为 baseurl=https://mirrors.aliyun.com/centos/8-stream/AppStream/x86_64/os/
上个月把thinkpad升级了固态硬盘后，彷佛打开了新世界的大门。想起了我2010年买的宏基4741g还在压箱底，何不也来次大换血？
这都2023年了，高性能的笔记本一抓一大把，14年前的电脑早该化成灰了，还有必要使用吗？
我想要升级老电脑的原因主要有两点：
就是玩，本人就是一个电子爱好者，平时就是喜欢把家电修修补补。 对于只是日常办公够用就行，不太追求极致的性能体验。 宏基4741g属于2010年的产品，当时买来是用于学习计算机使用的，一直用到2016年，期间也有过多次维修经历。因为散热差，经常因为工作开太多程序导致意外关机，所以购买了Thinkpad T450，从此让我有了最差的电脑使用体验。好在后来大多数时间都是使用公司提供的电脑，Thinkpad就放家里看看电影，写代码根本不想打开它，开机6分钟，命令行提示卡十几秒。而用了6年的acer 4741g都没让我受过这气。
所以，基本可以确定，10年买的宏基4741g在性能上比16年Thinkpad T450好不少，如果升级一下硬盘和内存，使用体验肯定不会差。
然后就是35元买了120G固态硬盘，35元的4G内存，10元买了硬盘盒。原来是32位win7系统，现在重装了64位win7，这样一升级性能至少翻倍，再用10年没毛病吧。
2016年初花大价钱买的thinkpad t450准备用来工作，结果发现性能太差，根本满不了需求。于是就放家里日常使用，即使这样还是无法忍受它的慢，慢到什么程度呢？开机到桌面3分钟，再到打开程序3分钟。这还不如我2010年买的2G内存i3电脑性能好。后来把内存从4G加到8G没有明显提升，那就剩下CPU和机械硬盘的问题了，CPU是低压版i5 4300U，和主板焊在一起，没法升级。前几年就想升级硬盘，但是那时候固态硬盘价格不便宜，也没有着急升级。直到最近才忍受不了，下定决心升级一下。
升级过程并不顺利……
首先是确定支持的接口，thinkpad t450已经装了一块16G固态硬盘，接口是M.2（即NGFF，现在已经改名为M.2了）
真实尺寸很小，22*40mm大小，就是2240型号。2280型号意思就是宽22长80，自然就是更大尺寸的。选择的时候要注意不要选错。
安装好以后使用傲梅分区助手进行系统迁移（之后遇到很多问题），然后在bios里修改启动顺序，结果左上角的光标一直闪，无法进入系统，修改为原HDD硬盘后还是可以启动的。网上有说法是磁盘盘符冲突，按照方法在注册表中调换盘符后还是进入不了系统，甚至原来的磁盘系统也进入不了。
无奈，只能重装系统。但是不能在原来的盘里装，需要直接装套SSD固态硬盘上。准备了8G U盘，4G肯定是不够的，win10系统就有4.5G以上了。下载winpe，直接安装到U盘里，然后将下载好的win10系统拷贝到winpe工具箱里。
再修改启动顺序重启系统，这时候也出现问题，识别不到U盘，我是在系统启动后再插上U盘，如果直接插上再启动就会识别不出来。进入到pe系统后首先通过系统安装器安装系统，又出现找不到iso系统文件的情况，重插U盘解决。但是选择目标盘后MBR始终是黄色，无法变成绿色，最后通过CGI工具还原的方式成功安装。
安装成功重启又出现boot menu界面，死活进入不了系统，这个是由于在bios中修改过启动方式引起的。有uefi和legacy两种模式，设置为both兼容模式启动。至此算是安装成功。
由于加了SSD固态硬盘，原来的盘符也有变化，SSD成了C盘，原来的C盘变成了D盘，以此类推。手动把原盘中的快捷方式拷贝过新盘，都用不了，可以通过属性-修改路径的方式修正。个别软件缺少dll动态链接库也可以从原盘找到，有两个目录可以查找windows-System32,windows-Syswow64。
总结：系统启动时间由3分钟提升到了30秒，到桌面也可以直接操作，不需要再等3分钟才能做操作。
go run和go build会报出一连串下面这样的警告信息，虽然不影响程序运行，但是看着难看。
# command-line-arguments ld: warning: object file (/var/folders/9p/2x3ls9kn7qb59hf9l9mtfs8s6rbmfg/T/go-link-3994413096/000000.o) was built for newer macOS version (12.0) than being linked (11.0) 解决方法：CGO_CFLAGS=-mmacosx-version-min=10.12 go run main.go，运行前加CGO_CFLAGS=-mmacosx-version-min=10.12参数可以解决。
vscode中可以通过配置launch.json文件实现：
{ "version": "0.2.0", "configurations": [ { "name": "Launch Package", "type": "go", "request": "launch", "env": { "CGO_CFLAGS":"-mmacosx-version-min=10.12" }, "program": "${fileDirname}", "args": [], "cwd": "${fileDirname}" } ] } 或者从文件中读取环境变量：
{ "version": "0.2.0", "configurations": [ { "name": "Launch Package", "type": "go", "request": "launch", "envFile": "${workspaceFolder}/.env", "program": "${fileDirname}", "args": [], "cwd": "${fileDirname}" } ] } 如果是在vscode中执行测试代码，则需要设置settings.
之前提到过关于svelte框架——sapper和sveltekit的发展，已经是1年前的事了，其中提到过svelte的框架sapper和sveltekit，sapper已经明确不再更新了，官方推荐的是sveltekit。然后经过两年的迭代更新，于2022年12月终于推出了1.0版本。可以看看官方博客对1.0的介绍Announcing SvelteKit 1.0。
然后谈谈个人感受。
优点： sveltekit集成的还不错，开发体验可以，使用官方提供的脚手架创建的项目就可以直接使用，不需要做任何配置。热更新，响应速度快，支持typescript等等，该有的都有了。
缺点： 又是一个全新轮子，这也是整个前端的通病，除了js是通用的，其他的都能给你整出花来，sveltekit在1.0版本之内已经有破坏性的更新，一年前创建的新项目，一年后基本不能用了。
至于要不要使用，那就看个人情况了，如果你厌烦了其他框架，倒是可以尝尝鲜，如果你想以此来做长期项目的话，个人就不推荐了，毕竟太新，而且向下兼容又做的不好，隔三差五一个破坏性更新，这种折腾劲恐怕没几个人受得了。而且对自己的技术也不能积累，长此以往并没有好处。
sveltekit官方文档
golang版本的elasticsearch批量插入和批量更新方法如下：
package main import ( "github.com/elastic/go-elasticsearch/v8" "github.com/elastic/go-elasticsearch/v8/esutil" ) func main() { list:=make(User, 0) bulkES(list) } func bulkES(list []User) error { indexer, err := esutil.NewBulkIndexer(esutil.BulkIndexerConfig{ Index: "search-user", Client: ES, }) if err != nil { return err } for _, v := range list { data, err := json.Marshal(v) if err != nil { return err } err = indexer.Add( context.Background(), esutil.BulkIndexerItem{ Action: "index", Body: bytes.NewReader(data), }, ) if err != nil { return err } } indexer.