windows server core 也是开机就是命令行那种，以前 exchange,sql server,ad 域控，aspx 很火的时候还是很多 windows 服务器的。不过毕竟是收费，现在基本都是 linux+mysql+nginx 了，docker 出来后就更不用说了。windows 的 docker 基本是个残疾版。

我都是一个三脚架加上一个水龙头 安装在水桶上直接倒过来 最多就换头 反正塑料头也很便宜

看了一眼文档，没有实际操作。arkTS 是带编译器的，可以进行 AOT 编译 （ https://developer.harmonyos.com/cn/develop/arkCompiler/）。然后通过下方地址再进去看了一眼，
指向了一个运行时仓库
https://gitee.com/openharmony/arkcompiler_ets_runtime
再看了一眼其他相关页面
https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/ARK-Runtime-Subsystem-zh.md
一直到最近都还在更新，如果鸿蒙真的用上了这些，说语言也不过分。

老运维个人理解：运维的本质其实在于系统持续运行和快速恢复。排查故障其实都是事后补助措施，所以很多运维需要做大量高可用设计方案。这里题目我没看到几道题跟高可用或者故障处理快速恢复相关。个人感觉这个公司对岗位定位有偏差

干脆去考 PMP 得了

@Morii #31 对公司而言，人力也是资源，也是流动的。接手一个项目本来就要熟悉之前的封装，除非你一直都只写最基础的业务。别人经验我不清楚，但是 Go 的门槛确实低，基本上业务层面上封装概念搞懂就行。拿 Python 举例，我见过比较恶心的一些例子，使用类似 flask 的 requst 绑定线程的变量，数据结构全程动态生成，一些自定义的装饰器，locals()获取当前变量名当作 key/value ，诸如此类等等等等。每次碰到这些东西，我就觉得 Go 设计太特么好了

合适啊，越复杂越合适呢，毕竟 Go 没啥特殊的语法，也就协程比较麻烦一点。再复杂的东西，你用 Go 写也就那样，大部分人都能看懂，软件后续维护其实真的很重要。毕竟人都是流动的。

getInstance 实际上就是强行跟代码耦合了，因为你依赖的是一个固定实例而且不可替换。某些代码层级不规范的情况下，很容易产生底层模块依赖上层模块导致循环依赖。写测试的时候必须把整个 GetInstance 的依赖链条都写完才能测试。
但是 fx 代码注入实际上依赖的只是一个 调用接口 /规范，真正的实例是运行后通过 fx 生成注入的。而且因为依赖注入必须要显示把所有依赖的东西都写到 New 上，某些不必要的依赖就可以 mock 甚至直接 nil 。
觉得 getInstace 简单，大概率还没碰上 getInstace 的 instance 再 getInstance 再 getInstance 循环这种？

你的例子里面 simpleApi 没有私有变量，加一个比如 id 然后 say 的例子用 id 加 name ，然后调用过程修改 id 试试就知道区别了

@pastor #66 能做的话都不是事，但是这种一般工作量太大了。涉及人和部门非常多，协作起来真的要命。除非整个 Ops 平台化建设都很完备才有可能这么搞

本老运维出来说一点点。
核心就是 B 站对运维投入应该不够重视。几个关键字，2021 年，自建机房，OpenResty+注册中心 ，线上网络和办公网络互通，关键业务 SLB 居然还要临时新建，业务回滚极不完善。

不过也是事后 BB 罢了，线上原因多种多样。运维做多了，个人觉得核心在于不是排查出问题或者解决问题，而是快速恢复，降低影响。所以一个老运维需要很清楚知道，一些改动可能影响的范围。

这里事故的关键点其实在于，利用 OpenResty 的灵活性，接入了一个可以动态获取网关配置的注册中心。也就是说 LB 的配置变更的核心在于注册中心配置下发的配置。(我以前公司任何可能改动到网关的配置审核都是三层审核)。这里我猜很有可能 B 站注册中心下发配置权限在另一个部门，而且可能绕开了线上运维人员的审核。然后整个事故报告里面没有提到一句下发错误配置的部门，整个事故报告围绕自身问题...似乎看到了一个已经被强势业务部门 PUA 成性的背锅老运维了。所以如何把关键变更权掌控在运维手上，或者至少有效通知到运维人员，才是运维的关键。但是这一点往往因为业务线太长，需要公司更高层级的支持，所以往往一个公司的运维好坏是跟公司整体相关的。强势业务部门就会以各种理由抵制这些手段，老板也会站在业务部门角度。没有任何办法，只能等血淋淋的线上事故发生之后，趁机搞一点运维建设。

另外好多人一说事故就提高可用，问题是高可用上限是没有边界的。公司不注重运维体系建设，盲目砸钱搞高可用，本来人就不多，还要加工作量，我只能说下次事故说不定指日可待

server 端的证书跟着客户端请求走。。这种用法也太怪了吧？

TLS 握手交换验证证书在你 HandleFunc("/")之前就完成了，TLS 证书配置则必须在 http server 启动前就配置好。。你们需求是不是搞错了因果关系。。

@peter520 @29 Go gin web ,别整什么 java python 这种语法糖多的语言框架，你写一半不懂才知道要还要学会各种语法糖封装的各种组件遭不住的

后端就建议别拿后端经验去套 js ， 还有先把阮一峰的 es6 教程看一下。。https://es6.ruanyifeng.com/ 本后端刚开始写前端都懵逼了，原生古早 js 跟现在的 es6 还有一堆乱七八糟的 es2005 2xxx 根本不是一回事。然后再去看 vue 吧。。
说前端混乱我觉得不是没有道理的，html css js 每个项目用的标准都不太一样，html 还是简单的，css 有各种 less sass ...js 就是什么 es6 es2005 es2015 啥的。然后框架 vue react angular 啥的，加上各种 babel npm 开发工具。。虽然写起来都不太难，但是整个体系下来感觉就是太混乱了。。

额 感觉是我理解错了 确实没见过。。不知道参数定义算不算参数语法表达式