[Feature] A 股 K 线颜色规则：open === close 时按前收判断（一字涨跌停/十字星/平盘）

[0DevAI]

Feature Description

背景

A 股主流软件（通达信、同花顺、东方财富等）的 K 线颜色一般不是简单的二选一：

1. 普通 K 线：

   • close > open：红色阳线
   • close < open：绿色阴线

2. open === close：

   • 与前一交易日 close 比较：
     • 高于昨收：红
     • 低于昨收：绿
     • 等于昨收：白/灰，常称平盘

3. 涨跌停：

   • 收盘价 ≥ 涨停价：红
   • 收盘价 ≤ 跌停价：绿
   • 一字涨跌停同样按涨/跌方向着色

所以 open === close 是一个特殊分支，不能简单当成 noChange，也不能全局改成 previous_close。

当前 klinecharts 的问题

klinecharts@10.0.3 目前只有两种 compareRule：

• current_open
• previous_close

CandleBarView.drawImp 当前逻辑大致是：

var comparePrice =
  styles.compareRule === 'current_open'
    ? open
    : (prev?.close ?? close)

if (close > comparePrice) {
  // upColor
} else if (close < comparePrice) {
  // downColor
} else {
  // noChangeColor
}

这会导致：

• 一字涨停：open === close，走 noChange。
  如果上层把 noChangeColor 设成上涨红，看起来会碰巧正确。

• 一字跌停：open === close，也走 noChange。
  如果 noChangeColor 是红色，一字跌停会被画成红色，这是错误的。

• T 字跌停、下跌十字星同理。

• 如果全局改用 previous_close，虽然一字跌停会正确，但“假阴线/假阳线”也会被改变：

  • 昨收 10，今开 10.5，今收 10.2
  • A 股主流习惯：close < open，阴线绿
  • previous_close 逻辑：close > prev.close，会被标红
  • 这和主流 A 股软件不一致

期望行为

希望新增一个可选的 compareRule，例如：

current_open_then_previous_close

规则：

close !== open  -> 与 open 比较
close === open  -> 与 prev.close 比较
prev 不存在     -> 回退到 close，即走 noChange

这样：

• 普通阳线/阴线保持现有行为
• 一字涨停、一字跌停、T 字板、上下跌十字星按昨收正确着色
• 完全平盘走 noChange，上层可设置成白/灰

To Do

具体实现建议

1. 扩展类型，保持旧值兼容：

export type CandleColorCompareRule =
  | 'current_open'
  | 'previous_close'
  | 'current_open_then_previous_close'

2. CandleBarView.drawImp 增加分支，旧行为不变：

var comparePrice

if (styles.compareRule === 'previous_close') {
  comparePrice = prev?.close ?? close
} else if (styles.compareRule === 'current_open_then_previous_close') {
  comparePrice = close === open
    ? (prev?.close ?? close)
    : open
} else {
  comparePrice = open
}

3. indicator.ohlc 复用同一类型和同一段逻辑。

4. 可选后续增强：
   如果希望精确识别涨跌停或支持“一字板单独颜色”（部分软件可把一字板设成黄色），可以在 KLineData 上增加：

isLimitUp?: boolean
isLimitDown?: boolean

或：

limitUpPrice?: number
limitDownPrice?: number

绘制时优先判断涨跌停标记，再做普通开收/昨收比较。

感谢维护者考虑这个需求。如果新增第三个 compareRule 的方式不合适，也可以接受其他 API 设计，例如增加 noChangeCompareRule。