必须安装yaml for kubernetes插件并手动绑定为yaml (kubernetes)语法，同时重启sublime、禁用tab缩进、设置draw_white_space和detect_indentation，才能实现apiversion变蓝、kind变绿等语义高亮与正确折叠。
Sublime Text 打开 service.yaml 一片灰白，不是配错了，是语法引擎没加载对
默认的 YAML 语法只认缩进和冒号，apiVersion、kind: Service、spec.template.spec.containers 全部当普通字符串处理，颜色一致、无法折叠、不标错——这不是主题问题，是作用域（scope）根本没匹配到 Kubernetes 语义。
必须换专用语法包：
- 按
Ctrl+Shift+P→ 输入Package Control: Install Package→ 安装YAML for Kubernetes（作者 mattfoster，适配 v1.20–1.30+） - 安装后必须重启 Sublime Text（部分版本不重启不加载新语法）
- 打开任意
.yaml文件 → 点右下角语言名 →Open all with current extension as…→ 选YAML (Kubernetes) - 验证：
apiVersion:变蓝、kind:变绿、spec.containers[].ports[]可逐层折叠
knative.dev/v1 的 Service 资源写错缩进，kubectl apply 不报错但 Pod 永远不起来
Kubernetes 解析器不“看齐”，只“数空格”。缩进错一位，containers 字段可能被吞掉，env 变成字符串字面量，Pod 卡在 ContainerCreating 或启动后立刻退出——而 kubectl apply 往往静默成功，因为 YAML 结构合法，只是语义丢失。
关键防护动作：
- 在
Preferences → Settings – User中加两行："draw_white_space": "all"（显示 · 和 →）、"detect_indentation": false（禁用自动探测，避免混入 Tab 后整文件缩进失控） - 同级字段必须缩进量完全一致（比如全是 2 空格，不能有的 2 有的 4）
- 禁用 Tab：确保
"translate_tabs_to_spaces": true已启用 - 每次保存后跑一次
kubectl apply --dry-run=client -f service.yaml -o yaml，失败即结构非法；成功也不代表业务正确，仅说明能转成 JSON
写 knative.dev/v1 Service 时，spec.template.spec 层级容易漏掉 containerConcurrency 或错放 timeoutSeconds
Knative Serving 的冷启动行为和资源隔离逻辑，高度依赖 spec.template.spec 下几个非 Kubernetes 原生字段。漏写或位置错，会导致请求超时、并发失控、甚至零副本缩容失效。
典型结构要点：
-
containerConcurrency必须在spec.template.spec下，不能放在containers内；值为0表示不限制，并发由 Istio/Kourier 网关层调度 -
timeoutSeconds是spec.template.spec的直系字段，不是容器属性；设为300（5 分钟）是常见安全上限，超过则网关直接返回 504 -
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev要写在annotations里，不是labels；写错位置会导致 HPA 不生效 -
revisionTimeoutSeconds控制 Revision 生命周期，影响镜像拉取失败重试窗口，建议显式设为600
DigitalOcean 上部署 Knative Service，status.url 返回 404 或 TLS 握手失败
DO 的托管 Kubernetes（DOKS）本身不提供 Knative 内置网关，status.url 依赖你手动部署的 Ingress（如 Kourier）或 Istio。URL 生成逻辑受 networking.internal.serving.knative.dev 配置影响，而非单纯 DNS 解析。
排查路径：
- 先确认
kubectl get pods -n knative-serving中kourier-gateway和net-kourier-controller处于Running - 检查
kubectl get configmap config-network -n knative-serving -o yaml，确认domainTemplate是{{.Name}}.{{.Domain}}且Domain已设为你的 DO Load Balancer IP 或域名 -
status.url域名必须解析到 DO Load Balancer 的公网 IP，且该 LB 后端已转发80/443到kourier-gateway的80/443端口 - TLS 终止默认由 Kourier 处理，若用自签名证书，需在
config-certmanagerConfigMap 中关闭自动签发，否则Ready状态卡在Progressing
最常被忽略的点：Knative 的 status.url 是内部生成的，不等于你 curl 的地址；它依赖网关组件与 ConfigMap 的联动，缺一不可。调试时别只盯着 kubectl get ksvc 输出，要一层层查 Revision、Route、Configuration 的状态。
